You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2011/06/22 02:10:27 UTC
Security Policy Service
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.
Re: Security Policy Service
Posted by Peter Firmstone <ji...@zeus.net.au>.
An implementation would work something like this:
1. When a djinn node starts, it discovers a Registrar (lets say it
uses secure discovery to eliminate registrar proxy unmarshalling
attacks.). The registrar would have method constraints enabled,
limiting who can submit services.
2. The node then looks up a Security Policy Advisory service, it
chooses one that can authenticate as an Administrator.
3. The client node then hands back a proxy (RemotePolicy service)
that the SecurityPolicyAdvisory service (using MethodConstraints
again to restrict access) uses to update the local security
policy, running as the administrator subject. The RemotePolicy
service implements Unreferenced, when the SecurityPolicyAdvisory
service is down, DGC will notify the RemotePolicy that it has
become unreferenced, so it can lookup another Security Policy
Advisory service and continue keeping it's security policy up to date.
(One reason explaining why I'd like to secure DGC).
What use is a Security Policy Service?
An example:
1. Lets for a moment imagine a hypothetical secure djinn environment,
this may span a number of physical locations where those locations
are connected via the internet, Registrars are used to unite this
environment. This secure djinn environment may also include a
number of different administrators, who represent cooperating
entities. Each entity controls his/her own Registrar's and
restricts the services registered to those he/she owns. Any other
known entity may lookup any of the services on any registrar.
2. Each entity signs their proxy codebases.
3. Additional entity's join the group over time.
4. Each entity has an Identity, represented by a Subject containing
authentication Certificates and Principals.
5. A security policy service would allow you to grant
DownloadPermission, to all and any CodeSources signed with
approved Certificates. The policy can be updated to include any
newly approved Certificates. DownloadPermission is a misnomer, it
prevents a class being defined, or loaded, it doesn't prevent it
being downloaded, the jar file actually gets downloaded prior to
the DownloadPermission check. This is useful for preventing
unmarshalling attacks from unknown attackers.
6. The policy also allows the administrator to update Permission's
granted to Principals.
7. A number of Permission's can be granted based on Principals and
CodeSource Certificate combinations. Note this doesn't eliminate
the need for a Service to verify it's proxy object or grant
Permissions to proxy's dynamically, but it can be used to
determine which GrantPermissions are allowed for such combinations.
To make it easier for clients to determine the Permission's a CodeSource
might require we could add something similar to the following to our jar
files:
OSGI-INF/permissions.perm
(org.osgi.framework.PackagePermission "javax.microedition.io" "import")
(org.osgi.framework.PackagePermission "org.osgi.service.io" "import")
(org.osgi.framework.PackagePermission "org.osgi.service.log" "import")
(org.osgi.framework.PackagePermission "org.osgi.util.tracker" "import")
(org.osgi.framework.PackagePermission "org.osgi.framework" "import")
(org.osgi.framework.PackagePermission "org.eclipse.equinox.internal.util.hash" "import")
(org.osgi.framework.PackagePermission "org.eclipse.equinox.internal.util.pool" "import")
(org.osgi.framework.PackagePermission "org.eclipse.equinox.internal.util.ref" "import")
(org.osgi.framework.PackagePermission "org.eclipse.equinox.internal.io" "export")
(org.osgi.framework.PackagePermission "org.eclipse.equinox.internal.io.impl" "export")
(org.osgi.framework.PackagePermission "org.eclipse.equinox.internal.io.util" "export")
(org.osgi.framework.PackagePermission "javax.microedition.io" "export")
(org.osgi.framework.BundlePermission "*" "provide")
(org.osgi.framework.BundlePermission "*" "host")
(org.osgi.framework.ServicePermission "org.osgi.service.io.ConnectionFactory" "get")
(org.osgi.framework.ServicePermission "org.osgi.service.io.ConnectorService" "register")
(java.util.PropertyPermission "*" "read")
(java.net.SocketPermission "*" "listen")
The above is an example of permissions.perm in an OSGi bundle jar file.
OSGi calls these Local Permissions. The semantics of OSGi are slightly
different with permissions.perm defining the maximum allowable
Permission's for a bundle, which when empty is only limited by
AllPermission, which is not really what we want.
But we could have something similar eg:
META-INF/permissions.perm
A client could parse this information to determine the Permissions a
proxy requires, the administrator can restrict by way of
GrantPermissions, the Permission's Principal's or clients are allowed to
grant to proxy's.
Some food for thought.
Cheers,
Peter.
Peter Firmstone 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.
>
>
>
>
>
>
>
>
>
Re: Security Policy Service
Posted by Peter <ji...@zeus.net.au>.
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" <ji...@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.
> >
> >
> >
> >
> >
> >
> >
> >
Re: Security Policy Service
Posted by Tom Hobbs <tv...@googlemail.com>.
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" <ji...@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.
>
>
>
>
>
>
>
>