river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michał Kłeczek <michal.klec...@xpro.biz>
Subject Re: Service lookup without unmarshalling - details
Date Sun, 14 Dec 2008 22:48:14 GMT
On Sunday, 14 of December 2008 22:08:50 Wade Chandler wrote:
> ----- Original Message ----
>
> > From: Michał Kłeczek <michal.kleczek@xpro.biz>
> > To: river-dev@incubator.apache.org
> > Sent: Sunday, December 14, 2008 7:10:19 AM
> > Subject: Re: Service lookup without unmarshalling - details
> >
> > Hi,
> >
> > This is a really interesting topic since it touches areas in River
> > architecture that have some holes. So these some of my thoughts:
> >
> > 1. We cannot get rid of SecurityManager since then we would have an "all
> > or nothing" security - once we say we trust downloaded code it is not
> > constrained in any way. In Jini we only trust the service up to the level
> > of the permissions we dynamically grant to it.
>
> I skipped over the call level security which needs to be address. OK, 
> still, I think we should be able to tell the core to relax or constrict and
> only import services from 1) servers or clients (connections) having this
> or that certificate (SSL) or credentials (Kerberos), 2) particular signers
> of code bases, 3) any pluggable abilities such as a way to sign some unique
> code base or attached security device, 4) specific classes and objects or
> URLs or any grouping of those things. Technically unbinded because all that
> is pluggable. That makes good sense in the cases where we have our own sets
> of services we code this way or that and don't really care which way or how
> the services behave as long as they are ours within our system. Now, in the
> cases where we need finer control or allow others to plug into our system
> then it gets more and more needed and call level security should be usable.

I am not 100% sure but in case of known codebases/signers everything is 
already in place in standard JRE. You can always make PreferredClassLoader 
check DownloadPermission.
It gets really interesting when you don't know anything about the downloaded 
code :)

>
> We can do a couple things, but on a high level we can 1) Extend
> ObjectInputStream and do some things there and 2) Have a 3rd party stream
> which we inject under the ObjectInputStream which we read from. We can then
> build a rule/state machine which we can build a customizable/implementable
> (how ever we want to look at it) system where we can have some simple and
> workable defaults that allow consumers/users to get off the ground more
> quickly and also to inject more rules as they need them for their specific
> environment or custom systems.

I am not sure how we can protect the client against:

private void readObject(ObjectInputStream is) {
  final Collection c = new ArrayList(){
  while (true) {
    try {
      c.add(new Object());
    } catch (Throwable t) {}
  }
}

We could augment ObjectInputStream so that no code gets executed during 
deserialization. But it would be opening a Pandora's box since now services 
could not just use standard Java serialization for their proxies.
Maybe some bytecode processing would be an option?

But of course - checking the size of the downloaded data + the possibility for 
the client to suppress code downloading for certain classes (aka never 
preferred classes) would at least allow the ServiceLookup to work reliably.

>
> With that and maybe some other things we do with ObjectInputStream and
> ObjectOutputStream or JERI and endpoints, look at src/net/jini/jeri/*, or
> whatever we can technically create such a system where if needed the extra
> security provided by such a 3rd party deserializer could be created from
> that yet wouldn't have to be something we have to do to get a pretty good
> system in place. So, we could do a lot to move River forward, and then
> later make those more complex additions as extra value adds once we have
> some other things in place.
>
> What do you think? Am I out in left field or does that sound like a decent
> starting point?

We have to start somewhere. It looks like right now nobody actually knows what 
to do with River anyway so... let's just start :) .

Michal

Mime
View raw message