On Sunday, 14 of December 2008 22:08:50 Wade Chandler wrote:
> ----- Original Message ----
>
> > From: Michał Kłeczek <[email protected]>
> > To: [email protected]
> > 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
