This is pretty much above my pay grade. The limit of my experience here has been a djinn limited to a single corporate's subnet(s), where the theory went "if its on my network, then I trust it.".
As such I've never needed more than a standard grant-all policy file. Grammar and spelling have been sacrificed on the altar of messaging via mobile device. On 22 Jun 2011 01:18, "Peter Firmstone" <j...@zeus.net.au> wrote: > 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. > > > > > > > >
