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
about:
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.
Cheers,
Peter.
