I don't know what is happening with your emails Michal. For some reason Yahoo puts them directly to the trash folder...anyways, seems I have to check their now before anything until I can figure that out...more inline.
----- Original Message ---- > From: Michał Kłeczek <[email protected]> > To: [email protected] > Sent: Sunday, December 14, 2008 5:48:14 PM > Subject: Re: Service lookup without unmarshalling - details > > On Sunday, 14 of December 2008 22:08:50 Wade Chandler wrote: > > ----- Original Message ---- > > > > > From: Michał Kłeczek > > > 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 :) > Yes, the base stuff is in the JDK/JRE. I just mean through River and those mentioned APIs to check codebases and even at the level of join and discovery. That way folks don't have to have everything setup at the JRE level. That allows River to control some things, or at least be more customizable if a system wants to use it, and we can build higher level tooling which makes that stuff more user friendly and we can make automating the security easier as well. Think of Applets, Web Start, Firefox, and other things which sandbox security. Applets and web start for instance, the user gets a popup asking if they want to allow this or that thing to run with these or those permissions which are signed by XYZ. Firefox can be configured to allow this or that unknown certificate and encrypted web site to be accessed directly versus just allowing its known trusts; things can be added. Having the ability to set that kind of stuff up in River under the hood for automated systems or through user interfaces for tooling in NB or Eclipse is what I'm specifically talking about being able to do. Make that more complex stuff we know we really need to do be able to do in different systems easy from the start. > > > > 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? > Yes, byte code processing is one option I was thinking of which can be injected under the object input stream. This would essentially be a virus scanner and then some. In River the sources for JERI anyways have to connect to an object input stream and output stream to write and read objects etc, and other transports can/will as well. I was mainly thinking about JERI here. There we can build a state engine to do different things. Byte code checks etc for security is one thing that can be added, even by a third party, and we can guard against DOS attacks etc. I may be misunderstanding something here, but looking through things it seems service lookup, using the River APIs means one will go through that common point to get initial hooks to a service. Other things happening after one has a proxy or service handle start to allow code freedom from where to get classes and how (smart proxies). At that point service developers can decide if they want to use or not use particular services the APIs provide. A given system, or the River core when customizable, can then decide if it wants to use those services once the initial service lookup has occurred. Does it meet this or that constraint. The same for a user of a graphical environment including an IDE. They can be asked specifics unless they have told the system to always trust code from XYZ or this particular server on the network...flexibility. For smart proxies and other service unique ways of accessing information and loading classes, if we are augmenting object input stream under the hood, which OO/OI streams are used now in River as services are used and objects are marshalled and unmarshalled, then it seems folks could just use those same mechanisms directly in their smart proxies, the augmented OO/OI streams, and we could have that be another reusable core set of APIs which are not necessarily only helpful to River but used for whatever. The direct connections from proxies are fine, and if one doesn't want to include that ability in their service then they should *not* have to use the extra security models just like they don't have to program directly to JERI now. Essentially they could do what ever they want to do from the services proxies. Now, of course, security settings can dictate that only the core can access object input stream directly within a given environment, and that lock down can be used by different systems to make sure they use only services which use secured services such as some kind of an augmented OO/OI stream API or something else. That would be on a system by system basis. Too, perhaps systems can be locked down by forcing particular classloader schemes so that code can't come in under the radar and define a classloader which pulls insecure code from other places. How exactly to do that I'm not exactly sure at this point, but that is another issue. But, all those ways of making back doors brings us back around to secure connections, trusted connections, and trusted code bases. i.e. not running just any code we find out on the network. Seems that is more and more important at that point. Much like running email attachments. > 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. > Indeed/Exactly. > > > > 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 :) . > Sounds good. Wade ================== Wade Chandler, CCE Software Engineer and Developer, Certified Forensic Computer Examiner, NetBeans Dream Team Member, and NetBeans Board Member http://www.certified-computer-examiner.com http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam http://www.netbeans.org
