river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <peter.firmst...@zeus.net.au>
Subject Update on progress
Date Sun, 28 Aug 2011 11:08:28 GMT
I noticed the list is rather quiet lately.

I've been making progress with my security work, most of it is low level 
work, most app developers won't need to concern themselves with it.

One of the problems with usability River is you can't totally ignore 
security, you still need to set up policy files because you are required 
to install a security manager.  So the new ProfilingSecurityManager will 
make life easy in this case, because it tells you all the permissions 
each codesource requires to run (it grants all by default).  It is left 
up to the app developer to decide if these permissions should then be 
granted to principals, or codebases or combinations of the two.

The other tool that is under development to make the implementers life 
easier is allowing jar files to provide the list of permissions they 
require, so these can be discovered at runtime and dynamically granted 
after authentication and proxy verification.

Moving onto the things the application developer doesn't need to worry 

   1. The new DynamicPolicyProvider now passes all qa tests and has some
      significant concurrency improvements, so security checks will be
      far less likely to restrict scalability. - Completed.
   2. I have a new PolicyFile that replaces com.sun.provider.PolicyFile,
      yes that's right, River has a dependency on Sun's jvm policy
      implementation, by default, although this can be changed by
      setting a property.  The new implementation is based on
      ApacheHarmony, but with modifications so it behaves identical to
      Sun's implementation to pass qa tests.  In addition I'm in the
      process of modifiying Harmony's PolicyParser implementation to
      support array expansion in policy files, which Sun's policy parser
      supports and Harmony's doesn't.  This will assist in supporting
      platforms other than Sun's.  On that subject, I think we need to
      separate the qa suite from the main build and use it as a library
      instead, if we want to support more than just Oracle's Sun jvm. 
      The new PolicyFile implementation caches the parsed policy files
      and also supports concurrency.  This passes all qa policy tests,
      but it fails tests when providers are required from jre/lib/ext
      because it doesn't yet support array expansion. - Nearly complete.
   3. RemotePolicy will utilse the PolicyParser above - TODO.
   4. A new SecurityManager implementation, to support logging failed
      security checks, for assisting trouble shooting problems in a
      djinn. - TODO.
   5. Delegates, I'll be creating some wrappers for SocketFactory and
      other similar classes, to prevent references escaping. I'm
      implementing a high performance DelegateSecurityManager, making
      method guard security possible and intrinsic in object
      implementation, eg: this can be used to protect against
      deserialization being used to inspect private state, etc.  This is
      far better than trying to add security on later, the most secure
      place for guard checks is in the object implementation on method
      calls. - Complete, more testing required.

To date due to the performance of the java security architecture and 
policy providers, it hasn't been practical to make security an object's 
implementation concern, but it will be very soon...

Soon you'll be able to have security sensitive fields in an object and 
have it completely protected by method guards, rather than just a 
constructor based guard, which is a compromise between security and 
performance, making it easier to write secure code.

Then I need to look further into the stuff Gregg's been talking about.



  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message