When deploying nodes in a Djinn, how do you currently manage your
security policies? How secure is your environment?
Java can use URL based policies, but this is subject to spoof attacks
and the URL cannot change without reconfiguring clients.
Currently the way the Java policy system works by reading in (parsing)
policy files, with the local policy provider.
Java policy's are permissive, which means you start with only the jre
and extensions having permissions, you then grant permission by
CodeSource, Certificates and Principals in policy files.
Once security is relaxed, to tighten it requires a restart, impractical
for a distributed environment, in reality it's designed for a local jvm.
A security policy service could be used by a codebase admin to restrict
download permissions. An admin might also like to be able to put a
limit on download size to avoid DOS and Domain spoofing attacks. In
addition a ClassLoadingPermission would be useful to restrict class
loading of CodeSource's to those signed with approved Certificates of
trusted developers or partners. The admin might also determine what
GrantPermission's can be made by different Principals.
Requirements of a distributed Security Policy Service:
1. The security policy's need to be manageable in one location for
administrators managing a number of nodes.
2. There may be several security policy services in a single djinn,
belonging to different cooperating entities, more than one
administrator http://nighthacks.com/roller/jag/resource/Fallacies.html
3. All nodes belonging to an entity are configured to lookup the
security service based on identity with secure InvocationConstraints.
4. Nodes are configured to register with a SecurityPolicy service
that can authenticate with an administrator subject.
5. Nodes retrieve a current policy from the SecurityPolicy service
6. The SecurityPolicy service notifies with a RemoteEvent when the
security policy has been updated.
7. Nodes update their security policies when notified of change.
8. Security policies must be idempotent, when a change is made to the
policy, clients must update the entire policy, they cannot make
incremental sequenced or ordered changes.
9. The SecurityPolicy service can only provide policy advise based on
CodeSource, Certificate's and Principals. They cannot make proxy
trust decisions or provide policy advise for Proxy's (ClassLoader
based dynamic permission grants), other than GrantPermission's
which are those that a local Subject has permission to grant to
proxy's.
10. Client nodes must update their security policy without shutting
down, a restart would cause all clients to do so at the same time
which creates issues with multicast packet storms, so the policy
must be capable of removing grants absent from the updated policy
without restarting.
11. A SecurityPolicy service would supplement the existing dynamic
grants used for Proxy's, it's important to realise that dynamic
proxy permission grants are a local concern and are granted to the
proxy's ClassLoader. Cleaning of grants deleted from the policy
made by the SecurityPolicy service must not remove dynamic grants
made to proxy's.
One important thing to remember regarding policy updates, some
permission grants even though they have been removed (depending on the
type of permission granted) fundamentally allow references to escape
after a security check is made, so once a reference to a security
sensitive object has been released, the SecurityManager has no further
control over it. DelegatePermission's and Delegate's are intended to
address this issue, using Li Gong's method guard pattern (Li Gong:
Inside Java 2 Platform Security, 2nd Edition, Page 176, 2nd last
paragraph ISBN: 0201787911). Programming with method guards in this
fashion also eliminates references escaping, making it easier to audit
code for security. To do so without degrading performance requires the
new InternetSecurityManager and DynamicConcurrentPolicyProvider
currently under development.
I'm also contemplating the possibility of a LoginModule service.
Cheers,
Peter.
