The easiest way for people to try out or start using River is without security. If we can encourage programmers learning . River to write proxy trust verifiers and use Subject.doAs even if they don't need it at the time, then security can be configured later when needed.
Cheers, Peter. ----- Original message ----- > 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" <[email protected]> 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. > > > > > > > > > > > > > > > >
