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/08/02 02:52:34 UTC
RemotePolicy service
Just get some feedback on this potential remote policy service. The
main intent here is to provide a secure centralised policy administrator
to simplify java security policy management for a djinn group. Note
this is new work, so it doesn't yet support encrypted policy files.
I've used code from Apache Harmony to parse standard syntax java policy
files.
Cheers,
Peter.
/*
* Licensed to the Apache Software Foundation (ASF) under one
* or more contributor license agreements. See the NOTICE file
* distributed with this work for additional information
* regarding copyright ownership. The ASF licenses this file
* to you under the Apache License, Version 2.0 (the
* "License"); you may not use this file except in compliance
* with the License. You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an "AS IS" BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.apache.river.api.security;
import java.io.IOException;
import net.jini.security.GrantPermission;
import net.jini.security.policy.UmbrellaGrantPermission;
import org.apache.river.impl.security.policy.util.PolicyParser;
import org.apache.river.impl.security.policy.util.DefaultPolicyParser;
import org.apache.river.impl.security.policy.util.DefaultPolicyScanner;
/**
* RemotePolicy is a service implemented by a Policy Provider, that allows
* the java security Policy to be updated remotely by a djinn group
administrator.
*
* For security purposes, only secure jeri Endpoint's should be used and
must
* require client and server authentication, in addition the proxy must
be a
* reflective proxy only, DownloadPermission should not be granted,
which is
* also beneficial to reduced network load at the administrator client.
* RemotePolicy may be submitted to a lookup service, where an
administrator
* client will look it up and replace PermissionGrant's periodically.
*
* To reduce network load, the administrator client may delay updates by
* lazily processing updates in a serial manner. New RemotePolicy services
* obtained by the administrator client's via RemoteEvent notification
should
* be processed as a priority over policy updates. Eventually a djinn group
* policy should reach equilibrium where all nodes have had their policy's
* updated.
*
* This policy, in addition to any local policy provider, allows a
network djinn
* administrator to provide a list of PermissionGrant's, from a single or
* replicated remote location, distributed to all nodes in a djinn
group the
* administrator is responsible for.
*
* In addition, replicating administrator clients may register a pseudo
RemotePolicy
* in order to track the primary administrator client and take over in the
* event it fails. Failure may be failure to authenticate or failure to
renew
* a Lease.
*
* RemotePolicy, if it encapsulates an underlying RemotePolicy, does not
* delegate updates to the base RemotePolicy, this is in case an
* implementer wants a number of different layers of RemotePolicy, where
* each layer represents a different administrator role or responsibility.
* The administrator's subject must hold the necessary permissions in order
* to grant them, including RuntimePermission("getProtectionDomain").
*
* A node may join more than one djinn group, in this case
RemotePolicy's may
* be used as nested basePolicy's.
*
* The intent of RemotePolicy is to simplify granting of
DowloadPermission to
* new signer Certificates and adding new Principals and Permission's to
* distributed policy providers.
*
* Local policy files should be used to restrict the Permissions grantable
* via a RemotePolicy.
*
* PermissionGrant's that are replaced and no longer exist in the
RemotePolicy
* will no longer be implied by the policy.
*
* DefaultPolicyParser has been provided for an administrator client to
* parse standard java format policy file's, to create PermissionGrant's
* custom policy file formats may be used by extending DefaultPolicyScanner.
*
* @author Peter Firmstone
* @see GrantPermission
* @see UmbrellaGrantPermission
* @see PolicyParser
* @see DefaultPolicyParser
* @see DefaultPolicyScanner
*/
public interface RemotePolicy {
/**
* Replaces the existing RemotePolicy's PermissionGrant's.
*
* The array is defensively copied, the caller, must have
* RuntimePermission("getProtectionDomain")
* as well as GrantPermission or UmbrellaGrantPermission for every
* Permission granted by each PermissionGrant.
*
* In this case the caller will be the client Subject.
*
* These Permissions should be set in the local policy files at the
* RemotePolicy server.
*
* @param policyPermissions
* @throws java.io.IOException
*/
public void replace(PermissionGrant[] policyPermissions) throws
IOException;
}
Re: RemotePolicy service
Posted by Peter Firmstone <ji...@zeus.net.au>.
Deployed nodes will still require some policy file configuration, for a
secure configuration, this is how deployment should work:
1. The node will need to be configured to authenticate itself an
administrator and a registrar.
2. Using secure discovery v2, the node discovers a ServiceRegistrar,
which is authenticated before code is downloaded.
3. The node then registers a RemotePolicy with the registrar and
awaits policy configuration by an authenticating administration
client (the local RemotePolicy service must also be authenticated
by the client).
4. The RemotePolicy service receives PermissionGrant's that define
the CodeSource Certificates required for DownloadPermission, this
prevents any unauthorised code from executing unmarshalling dos
attacks. It also receives grants for user Principals and
CodeSource Certificate combinations. This could be a djinn where
different company's (represented by groups, each responsible for
it's own registrar) systems interact, so different permissions
based on code signers from various companies and user principals
will determine the level of access at each node.
5. The node should now be ready to register any other services
provided with additional registrars and allow user access.
6. The node is free to look up services provided by other registrars
and join other groups.
7. If all endpoints used are secure and authentication is required
and proxy verification is used, we have a relatively secure djinn.
8. Actual Service API will be determined and agreed upon by the
cooperating entities, which may be added to registrars and systems
at any time.
DownloadPermission is a misnomer, it should be called a
ClassLoadPermission, because it doesn't guard against download, only
class loading. It may also be possible to restrict loading and related
dos attacks with ServiceUI, by requiring DownloadPermission by default
for all remote code.
Having introduced RemotePolicy earlier, you're probably wondering what
PermissionGrant is? (Please see earlier post for RemotePolicy details).
public interface RemotePolicy {
public void replace(PermissionGrant[] policyPermissions) throws
IOException;
}
PermissionGrant is an interface (appended), implementations of it
contain Permissions. The policy asks the PermissionGrant if it implies
a ProtectionDomain, during a permission check, if it does, the
Permissions granted by the PermissionGrant are added to the cache for
that ProtectionDomain, this includes any ProtectionDomains created by
SubjectDomainCombiner.
PermissionGrant's may be created by parsing java policy files with
PolicyParser, by using a PermissionGrantBuilder, or by asking an
existing PermissionGrant for a PermissionGrantBuilder.
PermissionGrantBuilder is an abstract class, with a static factory
method create(), that returns an implementation of
PermissionGrantBuilder. At this stage the implementation cannot be
changed by configuration, but that may change in future.
PermissionGrant implementations (there are currently 5) are
Serializable, yet immutable with all fields final. Instead of
serializing their internal state, they serialize a
PermissionGrantBuilder, which has a readResolve method that calls
build(), creating a new immutable PermissionGrant object at the remote end.
No implementation details are published publicly, no public
constructors, not even serialized state. To the client developer, there
is only a single type of PermissionGrant, which can be obtained via a
builder or a policy file parser. For release evolution, if deployed
nodes end up with different versions of builders, with new types of
PermissionGrant's, the builder will select the most appropriate
implementation upon deserialization. The implementation is flexible for
release evolution.
This is important to keep life simple for the application developer, the
builder selects the most appropriate implementation, based on the
methods called, so the developer doesn't need to investigate all the
implementations to figure out which is most applicable.
Further, because the policy resides in the extension class loader
(jre/lib/ext/), the PermissionGrant interface and abstract class
PermissionGrantBuilder must too, but the implementations (which the
policy can't see) don't need to.
The new Concurrent DynamicPolicy implementation also uses
PermissionGrant internally (via the builder) to create dynamic grant's,
the dyanamic grants are still called using the existing method in
DynamicPolicy, but it reduces the need for additional implementation
private classes in the policy for the grants, making the policy easier
to understand and read.
There is one last complication, because the Policy doesn't know the
implementation of PermissionGrant, it can't trust it's immutibility, for
security purposes, it must extract all permissions and check the current
call stack has the permission to grant them, if so the policy stores the
permissions in a ConcurrentMap for later retrieval, it never again asks
the PermissionGrant for the permission's it contains, it only asks if it
implies(ProtectionDomain), or if it isVoid(). Eg: A PermissionGrant
becomes void if it has been granted to a ClassLoader, which becomes
later garbage collected.
PermissionGrant's are not intended to be remote objects.
In case you noticed, Exclusion is for convenience, to exclude one or
more CodeSource or URL's (eg a third party library you've signed and
deployed) from receiving a blanket grant, applied to Subject Principals
and jar files signed by your Certificate's.
It's often the case that third party libraries have more functionality
than you need, you may not have access to source code to fix
vulnerabilities, so not granting Permission's that you don't require (by
exclusion) in a grant you've made to all ProtectionDomains, that contain
Subject Principals and CodeSource's signed with your Certificates, which
an attacker could use where a vulnerability exists is common sense. When
you sign and deploy these libraries along with your code, it saves you
from having to sign them with a different signer certificate.
Exclusions are not supported by standard java policy files.
/**
* PermissionGrant's are expected to be effectively immutable,
* threadsafe and have a good hashCode implementation to perform well in
* Collections.
*
* You shouldn't pass around PermissionGrant's to just anyone as they can
* provide an attacker with information about which Permission's may be
granted.
*
* @author Peter Firmstone
*/
public interface PermissionGrant {
/**
* A DynamicPolicy implementation can use a PermissionGrant as a
container
* for Dynamic Grant's. A PermissionGrant is first asked by the Policy
* if it applies to a Particular ProtectionDomain, if it does, the
Policy
* calls getPermissions.
*
* Dynamic grants can be denied to some ProtectionDomains based on
* CodeSource or URL's for codebases, this is to remove the
possiblity of
* executing Permissions for vulnerable codebases, once a vulnerability
* is identified after the fact.
*
* @param pd ProtectionDomain
* @return
* @see RevokeableDynamicPolicy
*/
boolean implies(ProtectionDomain pd);
/**
* Checks if this PermissionGrant applies to the passed in ClassLoader
* and Principal's.
*
* Note that if this method returns false, it doesn't necessarily mean
* that the grant will not apply to the ClassLoader, since it will
depend on
* the contents of the ClassLoader and that is indeterminate. It just
* indicates that the grant definitely does apply if it returns true.
*
* If this method returns false, follow up using the
ProtectionDomain for a
* more specific test, which may return true.
*/
boolean implies(ClassLoader cl, Principal[] pal);
/**
* Checks if this PermissionGrant applies to the passed in CodeSource
* and Principal's.
* @param cs
* @return
*/
boolean implies(CodeSource codeSource, Principal[] pal);
@Override
boolean equals(Object o);
/**
* Returns an unmodifiable Collection of permissions defined by this
* PermissionGrant, which may be empty, but not null.
* @return
*/
Collection<Permission> getPermissions();
@Override
int hashCode();
/**
* Returns true if this PermissionGrant defines no Permissions, or if
* a PermissionGrant was made to a ProtectionDomain that no longer
exists,
* or if the Exclusion excludes the PermissionGrant.
*/
public boolean isVoid(Exclusion excl);
}
Re: RemotePolicy service
Posted by Peter Firmstone <ji...@zeus.net.au>.
Dan Creswell wrote:
> How will an administrator know when their djinn has reached equilibrium?
>
> Answer: Probably by observation rather than providing a guaranteed time period.
>
> Next question: Do your interfaces support the administrator need to
> understand their djinn's behaviour?
>
Basically anything you can specify in an existing Java policy file, can
be performed by the RemotePolicy.
So you can take your local policy files on one node and replicate it
across all nodes.
The best way to understand the impact is to trial it in a small djinn first.
You can't perform dynamic proxy grant's to ClassLoader's, this still has
to be done locally (I have a way in mind to attach the Permissions code
requires to the jar file, to make it easy for the client to determine
the proxy's required permissions, but that's another topic).
I've pondered having a logging service, to log SecurityException's,
however the difficulty is one change could cause an avalanche of
logging, a self inflicted denial of service.
Perhaps an AdminLog, that could be obtained through administrable, I'm
not sure.
It would be possible to have a pseudo RemotePolicy service that logs the
updates and prints PermissionGrant's, so an administrator can view
changes as they occur remotely.
Any ideas?
Cheers,
Peter.
> On 2 August 2011 01:52, Peter Firmstone <ji...@zeus.net.au> wrote:
>
>> Just get some feedback on this potential remote policy service. The main
>> intent here is to provide a secure centralised policy administrator to
>> simplify java security policy management for a djinn group. Note this is
>> new work, so it doesn't yet support encrypted policy files.
>>
>> I've used code from Apache Harmony to parse standard syntax java policy
>> files.
>>
>> Cheers,
>>
>> Peter.
>>
>>
>> /*
>> * Licensed to the Apache Software Foundation (ASF) under one
>> * or more contributor license agreements. See the NOTICE file
>> * distributed with this work for additional information
>> * regarding copyright ownership. The ASF licenses this file
>> * to you under the Apache License, Version 2.0 (the
>> * "License"); you may not use this file except in compliance
>> * with the License. You may obtain a copy of the License at
>> *
>> * http://www.apache.org/licenses/LICENSE-2.0
>> *
>> * Unless required by applicable law or agreed to in writing, software
>> * distributed under the License is distributed on an "AS IS" BASIS,
>> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>> * See the License for the specific language governing permissions and
>> * limitations under the License.
>> */
>>
>> package org.apache.river.api.security;
>>
>> import java.io.IOException;
>> import net.jini.security.GrantPermission;
>> import net.jini.security.policy.UmbrellaGrantPermission;
>> import org.apache.river.impl.security.policy.util.PolicyParser;
>> import org.apache.river.impl.security.policy.util.DefaultPolicyParser;
>> import org.apache.river.impl.security.policy.util.DefaultPolicyScanner;
>>
>> /**
>> * RemotePolicy is a service implemented by a Policy Provider, that allows
>> * the java security Policy to be updated remotely by a djinn group
>> administrator.
>> *
>> * For security purposes, only secure jeri Endpoint's should be used and must
>> * require client and server authentication, in addition the proxy must be a
>> * reflective proxy only, DownloadPermission should not be granted, which is
>> * also beneficial to reduced network load at the administrator client. *
>> RemotePolicy may be submitted to a lookup service, where an administrator
>> * client will look it up and replace PermissionGrant's periodically.
>> *
>> * To reduce network load, the administrator client may delay updates by
>> * lazily processing updates in a serial manner. New RemotePolicy services
>> * obtained by the administrator client's via RemoteEvent notification should
>> * be processed as a priority over policy updates. Eventually a djinn group
>> * policy should reach equilibrium where all nodes have had their policy's
>> * updated.
>> *
>> * This policy, in addition to any local policy provider, allows a network
>> djinn
>> * administrator to provide a list of PermissionGrant's, from a single or
>> * replicated remote location, distributed to all nodes in a djinn group the
>> * administrator is responsible for.
>> *
>> * In addition, replicating administrator clients may register a pseudo
>> RemotePolicy
>> * in order to track the primary administrator client and take over in the
>> * event it fails. Failure may be failure to authenticate or failure to
>> renew
>> * a Lease.
>> *
>> * RemotePolicy, if it encapsulates an underlying RemotePolicy, does not
>> * delegate updates to the base RemotePolicy, this is in case an
>> * implementer wants a number of different layers of RemotePolicy, where
>> * each layer represents a different administrator role or responsibility. *
>> The administrator's subject must hold the necessary permissions in order
>> * to grant them, including RuntimePermission("getProtectionDomain").
>> *
>> * A node may join more than one djinn group, in this case RemotePolicy's may
>> * be used as nested basePolicy's.
>> *
>> * The intent of RemotePolicy is to simplify granting of DowloadPermission to
>> * new signer Certificates and adding new Principals and Permission's to
>> * distributed policy providers.
>> *
>> * Local policy files should be used to restrict the Permissions grantable
>> * via a RemotePolicy.
>> *
>> * PermissionGrant's that are replaced and no longer exist in the
>> RemotePolicy
>> * will no longer be implied by the policy.
>> *
>> * DefaultPolicyParser has been provided for an administrator client to
>> * parse standard java format policy file's, to create PermissionGrant's
>> * custom policy file formats may be used by extending DefaultPolicyScanner.
>> *
>> * @author Peter Firmstone
>> * @see GrantPermission
>> * @see UmbrellaGrantPermission
>> * @see PolicyParser
>> * @see DefaultPolicyParser
>> * @see DefaultPolicyScanner
>> */
>> public interface RemotePolicy {
>> /**
>> * Replaces the existing RemotePolicy's PermissionGrant's.
>> *
>> * The array is defensively copied, the caller, must have
>> * RuntimePermission("getProtectionDomain")
>> * as well as GrantPermission or UmbrellaGrantPermission for every
>> * Permission granted by each PermissionGrant.
>> *
>> * In this case the caller will be the client Subject.
>> *
>> * These Permissions should be set in the local policy files at the
>> * RemotePolicy server.
>> *
>> * @param policyPermissions
>> * @throws java.io.IOException
>> */
>> public void replace(PermissionGrant[] policyPermissions) throws
>> IOException;
>> }
>>
>>
>>
>
>
Re: RemotePolicy service
Posted by Peter Firmstone <ji...@zeus.net.au>.
>>
>> The big issues, are always about "security" as a starting point.
>> And it's hard to manage security without some pre-established
>> settings. What do we all think about a "default" security
>> configuration (such as binding to localhost, asserting a download
>> permission and using SSL) that fall out of the APIs (or new APIs)
>> more naturally.
>
> Yes definitely, perhaps we also need to provide an insecure
> alternative also.
>
> Java 2 security is difficult to understand, even when you author code,
> you don't necessarily know what guards your method calls will end up
> invoking. The biggest problem is developers don't define the
> permissions their code needs and administrators don't know what to
> specify in their policy files.
>
> I've been working on ways to cut through the maze:
>
> com.sun.jini.tool.DebugDynamicPolicy was designed to capture policy
> security checks to assist developers to determine permissions required.
>
> In addition we now have com.sun.jini.tool.ProfilingSecurityManager
> (Original Author: Mark Petrovic BSD License)
>
> Why do we need two tools?
>
> DebugDynamicPolicy only tells you what permissions are required.
>
> ProfilingSecurityManager tells you what permissions each jar requires,
> it will also tell you permission checks made by static
> ProtectionDomain's.
> Prior to Java 1.4, ProtectionDomain's were immutable, the policy was
> only consulted at the time the ProtectionDomain was created, all
> permissions were CodeSource based (static). Java 1.4 added dynamic
> policy and principal based permission grants. Some of these old
> "static" ProtectionDomain's still exist in code, so you need a
> SecurityManager to capture their security checks, the policy will
> never be consulted.
>
> Something not well known is your SecurityManager and Policy should be
> specified on the command line together at jvm startup. Due to out of
> order optimisations, the point in time when a SecurityManager is
> loaded (when called from your code) can differ by platform, leading
> some platforms to require additional permissions, sometimes this will
> also crop up when making subtle changes. This often happens with our
> qa test suite, I do intend to fix it a some point.
>
> Soon I intend to borrow some code from Apache Felix, allowing smart
> proxy's to declare the permissions they require in their jar.
>
> As I mentioned on the Security policy Service thread, OSGi uses a
> permissions.perms file to describe a bundle's (jar file) local
> permissions.
>
> The apache felix classes that parse this file are:
>
> org.osgi.service.permissionadmin.PermissionInfo
> org.apache.felix.framework.security.util.LocalPermissions
>
> It appears pretty simple to make use of this file format with proven
> code for retrieving permissions from jar files.
>
> Developers can use ProfilingSecurityManager to determine what
> permissions their proxy jar requires.
>
> Then client's only need ask a proxy, what permissions it requires and
> if acceptable, grant them, after authentication and proxy
> verification. If unacceptable, the client can find another service
> instance.
>
The output below is one of the qa tests run with the
ProfilingSecurityManager enabled.
Remember whenever a security check is made, the AccessController must
check every ProtectionDomain on the current thread stack, unless called
from a doPrivileged method.
It's possible to alter this program to produce policy file output
instead. These policy files will still need some editing, but it
simplifies deployment. It might also be useful for generating
permissions.perms files for including in proxy jar files.
[java] -----------------------------------------
[java]
[java] Running
com/sun/jini/test/spec/url/httpmd/handler/OpenConnectionNonExistFile.td
[java] Time is Thu Aug 04 12:43:37 EST 2011
[java] Starting test in separate process with command:
[java] /usr/jdk/instances/jdk1.6.0/jre/bin/java
-Djava.security.policy=file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/harness/policy/defaulttest.policy
-cp
/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar:/opt/src/River2.2.1/peterConcurrentPolicy/lib/jsk-platform.jar:/opt/src/River2.2.1/peterConcurrentPolicy/lib/jsk-lib.jar
-client
-Djava.ext.dirs=/usr/jdk/instances/jdk1.6.0/jre/lib/ext:/usr/jdk/packages/lib/ext:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib-ext:/opt/src/River2.2.1/peterConcurrentPolicy/lib-ext
-Djava.security.manager=com.sun.jini.tool.ProfilingSecurityManager
-Dcom.sun.jini.jsk.port=9080 -Dcom.sun.jini.qa.port=9081
-Dcom.sun.jini.jsk.home=/opt/src/River2.2.1/peterConcurrentPolicy
-Dcom.sun.jini.qa.home=/opt/src/River2.2.1/peterConcurrentPolicy/qa
-Dcom.sun.jini.qa.harness.harnessJar=/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar
-Dcom.sun.jini.qa.harness.testJar=/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar
-Dcom.sun.jini.qa.harness.runjiniserver=false
-Dcom.sun.jini.qa.harness.runkitserver=false
-Djava.security.properties=file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/harness/trust/dynamic-policy.properties
-Dcom.sun.jini.qa.harness.testhosts=
-Djava.util.logging.config.file=/opt/src/River2.2.1/peterConcurrentPolicy/qa/src/com/sun/jini/test/resources/qa1.logging
-Dcom.sun.jini.test.home=/opt/src/River2.2.1/peterConcurrentPolicy/qa
-Dcom.sun.jini.test.port=9082
-Dcom.sun.jini.qa.harness.policies=file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/src/com/sun/jini/test/resources/jinitest.policy
-Djava.ext.dirs=/usr/jdk/instances/jdk1.6.0/jre/lib/ext:/usr/jdk/packages/lib/ext:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib-ext:/opt/src/River2.2.1/peterConcurrentPolicy/lib-ext
-Djava.protocol.handler.pkgs=net.jini.url
com.sun.jini.qa.harness.MasterTest
com/sun/jini/test/spec/url/httpmd/handler/OpenConnectionNonExistFile.td
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.lang.RuntimePermission "setIO", "";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.logging.LoggingPermission "control", "";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "line.separator", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"com.sun.jini.qa.harness.testhosts", "read";};
[java] grant codeBase
"file:/usr/jdk/instances/jdk1.6.0/jre/lib/ext/sunpkcs11.jar"
{permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.util", "";};
[java] grant codeBase
"file:/usr/jdk/instances/jdk1.6.0/jre/lib/ext/sunpkcs11.jar"
{permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.action", "";};
[java] grant codeBase
"file:/usr/jdk/instances/jdk1.6.0/jre/lib/ext/sunpkcs11.jar"
{permission java.util.PropertyPermission
"sun.security.pkcs11.allowSingleThreadedModules", "read";};
[java] grant codeBase
"file:/usr/jdk/instances/jdk1.6.0/jre/lib/ext/sunpkcs11.jar"
{permission java.io.FilePermission
"/usr/jdk/instances/jdk1.6.0/jre/lib/security/sunpkcs11-solaris.cfg",
"read";};
[java] grant codeBase
"file:/usr/jdk/instances/jdk1.6.0/jre/lib/ext/sunpkcs11.jar"
{permission java.util.PropertyPermission "os.name", "read";};
[java] grant codeBase
"file:/usr/jdk/instances/jdk1.6.0/jre/lib/ext/sunpkcs11.jar"
{permission java.util.PropertyPermission "os.arch", "read";};
[java] grant codeBase
"file:/usr/jdk/instances/jdk1.6.0/jre/lib/ext/sunpkcs11.jar"
{permission java.io.FilePermission "/usr/lib/libpkcs11.so", "read";};
[java] grant codeBase
"file:/usr/jdk/instances/jdk1.6.0/jre/lib/ext/sunpkcs11.jar"
{permission java.lang.RuntimePermission "loadLibrary.j2pkcs11", "";};
[java] grant codeBase
"file:/usr/jdk/instances/jdk1.6.0/jre/lib/ext/sunpkcs11.jar"
{permission java.io.FilePermission
"/usr/jdk/instances/jdk1.6.0/jre/lib/ext/sparc/libj2pkcs11.so", "read";};
[java] grant codeBase
"file:/usr/jdk/instances/jdk1.6.0/jre/lib/ext/sunpkcs11.jar"
{permission java.io.FilePermission
"/usr/jdk/instances/jdk1.6.0/jre/lib/ext/libj2pkcs11.so", "read";};
[java] grant codeBase
"file:/usr/jdk/instances/jdk1.6.0/jre/lib/ext/sunpkcs11.jar"
{permission java.io.FilePermission
"/usr/jdk/packages/lib/ext/sparc/libj2pkcs11.so", "read";};
[java] grant codeBase
"file:/usr/jdk/instances/jdk1.6.0/jre/lib/ext/sunpkcs11.jar"
{permission java.io.FilePermission
"/usr/jdk/packages/lib/ext/libj2pkcs11.so", "read";};
[java] grant codeBase
"file:/usr/jdk/instances/jdk1.6.0/jre/lib/ext/sunpkcs11.jar"
{permission java.io.FilePermission
"/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib-ext/sparc/libj2pkcs11.so",
"read";};
[java] grant codeBase
"file:/usr/jdk/instances/jdk1.6.0/jre/lib/ext/sunpkcs11.jar"
{permission java.io.FilePermission
"/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib-ext/libj2pkcs11.so",
"read";};
[java] grant codeBase
"file:/usr/jdk/instances/jdk1.6.0/jre/lib/ext/sunpkcs11.jar"
{permission java.io.FilePermission
"/opt/src/River2.2.1/peterConcurrentPolicy/lib-ext/sparc/libj2pkcs11.so",
"read";};
[java] grant codeBase
"file:/usr/jdk/instances/jdk1.6.0/jre/lib/ext/sunpkcs11.jar"
{permission java.io.FilePermission
"/opt/src/River2.2.1/peterConcurrentPolicy/lib-ext/libj2pkcs11.so",
"read";};
[java] grant codeBase
"file:/usr/jdk/instances/jdk1.6.0/jre/lib/ext/sunpkcs11.jar"
{permission java.security.SecurityPermission
"putProviderProperty.SunPKCS11-Solaris", "";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.lang.RuntimePermission "getenv.SOUL", "";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.io.FilePermission
"/opt/src/River2.2.1/peterConcurrentPolicy/qa/soul/soul.201108041053007925",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "net.jini.discovery.announce",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "net.jini.discovery.announce",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/lib/jsk-platform.jar"
{permission java.lang.RuntimePermission "createSecurityManager", "";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/lib/jsk-platform.jar"
{permission java.security.SecurityPermission "getDomainCombiner", "";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/lib/jsk-platform.jar"
{permission java.lang.RuntimePermission "getProtectionDomain", "";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/lib/jsk-platform.jar"
{permission java.security.SecurityPermission
"createAccessControlContext", "";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "testFailureAnalyzers", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"com.sun.jini.qa.harness.callAutoT", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.lang.RuntimePermission
"accessClassInPackage.sun.util.logging.resources", "";};
[java]
[java] TIME: 12:43:40 PM
[java]
[java] MasterTest.doTest INFO:
[java] ============================== CALLING SETUP()
==============================
[java]
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"com.sun.jini.qa.harness.startDelay", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission
"com.sun.jini.qa.harness.startDelay", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"com.sun.jini.qa.harness.runkitserver", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission
"com.sun.jini.qa.harness.runkitserver", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"com.sun.jini.qa.harness.runjiniserver", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission
"com.sun.jini.qa.harness.runjiniserver", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"com.sun.jini.qa.harness.testClassServer", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission
"com.sun.jini.qa.harness.testClassServer", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"com.sun.jini.qa.harness.serviceMode", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission
"com.sun.jini.qa.harness.serviceMode", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"testClassServer.transient.impl", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission
"testClassServer.transient.impl", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "testClassServer.adminName",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "testClassServer.adminName",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "testClassServer.type.1",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "testClassServer.type.1",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "testClassServer.type.0",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "testClassServer.type.0",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "testClassServer.type", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "testClassServer.type", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"testClassServer.classServer.impl.0", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission
"testClassServer.classServer.impl.0", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"testClassServer.classServer.impl", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission
"testClassServer.classServer.impl", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "testClassServer.impl.0",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "testClassServer.impl.0",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "testClassServer.impl", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "testClassServer.impl", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"testClassServer.classServer.port.0", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission
"testClassServer.classServer.port.0", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"testClassServer.classServer.port", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission
"testClassServer.classServer.port", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "testClassServer.port.0",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "testClassServer.port.0",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "testClassServer.port", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "testClassServer.port", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "com.sun.jini.test.port",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "com.sun.jini.test.port",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"testClassServer.classServer.dir.0", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission
"testClassServer.classServer.dir.0", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"testClassServer.classServer.dir", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission
"testClassServer.classServer.dir", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "testClassServer.dir.0", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "testClassServer.dir.0", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "testClassServer.dir", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "testClassServer.dir", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "java.io.tmpdir", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "java.io.tmpdir", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"com.sun.jini.qa.harness.globalvmargs", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission
"com.sun.jini.qa.harness.globalvmargs", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "java.ext.dirs", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "java.ext.dirs", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "com.sun.jini.jsk.port", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "com.sun.jini.jsk.port", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "com.sun.jini.qa.port", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "com.sun.jini.qa.port", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "com.sun.jini.jsk.home", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "com.sun.jini.jsk.home", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "com.sun.jini.qa.home", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "com.sun.jini.qa.home", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"com.sun.jini.qa.harness.securityproperties", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission
"com.sun.jini.qa.harness.securityproperties", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.io.FilePermission
"harness/trust/dynamic-policy.properties", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.io.FilePermission
"harness/trust/dynamic-policy.properties", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "user.dir", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "user.dir", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.io.FilePermission
"/opt/src/River2.2.1/peterConcurrentPolicy/qa/harness/trust/dynamic-policy.properties",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.io.FilePermission
"/opt/src/River2.2.1/peterConcurrentPolicy/qa/harness/trust/dynamic-policy.properties",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission
"com.sun.jini.qa.harness.testhosts", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"java.util.logging.config.file", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission
"java.util.logging.config.file", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "com.sun.jini.test.home",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "com.sun.jini.test.home",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.io.FilePermission
"src/com/sun/jini/test/resources/jinitest.policy", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.io.FilePermission
"src/com/sun/jini/test/resources/jinitest.policy", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.io.FilePermission
"/opt/src/River2.2.1/peterConcurrentPolicy/qa/src/com/sun/jini/test/resources/jinitest.policy",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.io.FilePermission
"/opt/src/River2.2.1/peterConcurrentPolicy/qa/src/com/sun/jini/test/resources/jinitest.policy",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"testClassServer.classServer.serverjvmargs.0", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission
"testClassServer.classServer.serverjvmargs.0", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"testClassServer.classServer.serverjvmargs", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission
"testClassServer.classServer.serverjvmargs", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"testClassServer.serverjvmargs.0", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission
"testClassServer.serverjvmargs.0", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"testClassServer.serverjvmargs", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission
"testClassServer.serverjvmargs", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.net.SocketPermission "localhost:9082", "listen,resolve";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.net.SocketPermission "localhost:9082", "listen,resolve";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.net.NetPermission "specifyStreamHandler", "";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.net.NetPermission "specifyStreamHandler", "";};
[java] 04/08/2011 12:43:40 PM com.sun.jini.tool.ClassServer run
[java] INFO: ClassServer started [[/var/tmp/], port 9082]
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "OpenConnection.Url", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "OpenConnection.Url", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "OpenConnection.ExpResult",
"read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.util.PropertyPermission "OpenConnection.ExpResult",
"read";};
[java] MasterTest.doTest INFO:
[java] =============================== CALLING RUN()
===============================
[java]
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission "os.name", "read";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/lib/jsk-platform.jar"
{permission java.net.SocketPermission "localhost:80", "connect,resolve";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.net.SocketPermission "localhost:80", "connect,resolve";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.net.SocketPermission "localhost:80", "connect,resolve";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/lib/jsk-platform.jar"
{permission java.net.SocketPermission "localhost", "resolve";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.net.SocketPermission "localhost", "resolve";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.net.SocketPermission "localhost", "resolve";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/lib/jsk-platform.jar"
{permission java.net.SocketPermission "127.0.0.1:80", "connect,resolve";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jinitests.jar"
{permission java.net.SocketPermission "127.0.0.1:80", "connect,resolve";};
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.net.SocketPermission "127.0.0.1:80", "connect,resolve";};
[java] MasterTest.doTest INFO:
[java] ============================ CALLING TEARDOWN()
=============================
[java]
[java] grant codeBase
"file:/opt/src/River2.2.1/peterConcurrentPolicy/qa/lib/jiniharness.jar"
{permission java.util.PropertyPermission
"com.sun.jini.qa.harness.nSecsWaitDestroy", "read";};
[java] 04/08/2011 12:43:41 PM com.sun.jini.tool.ClassServer terminate
[java] INFO: ClassServer terminated [port 9082]
[java] 04/08/2011 12:43:41 PM com.sun.jini.tool.ClassServer terminate
[java] INFO: ClassServer terminated [port 9082]
[java]
[java] TIME: 12:43:41 PM
[java]
[java] Test process was destroyed and returned code 0
[java]
com/sun/jini/test/spec/url/httpmd/handler/OpenConnectionNonExistFile.td
[java] Test Passed: OK
[java]
[java]
[java] -----------------------------------------
Re: RemotePolicy service
Posted by Peter Firmstone <ji...@zeus.net.au>.
Gregg Wonderly wrote:
> On 8/2/2011 3:15 AM, Dan Creswell wrote:
>> How will an administrator know when their djinn has reached equilibrium?
>>
>> Answer: Probably by observation rather than providing a guaranteed
>> time period.
>>
>> Next question: Do your interfaces support the administrator need to
>> understand their djinn's behaviour?
>
> This is where I think there is a giant "hole" in management for Jini.
> We could provide something through JMX (with a jini connector perhaps)
> as a "use what others might have" mechanism. But, in the end, it
> seems like we really need to have a "local service" that is
> automatically secured that services connect to and announce state,
> exceptions etc. That local service would be the one with a JMX
> interface I think. Basically, I still find boot-strapping services to
> be frustratingly prolonged because there's so much "initial" stuff
> that has to be "right" before something "sane" happens. If we could
> standardize such a "local service" and it's interface, then we might
> be able to at least provide generic tooling that would make a lot of
> things "just work". In the end, that "local service" should feel as
> easy to use as "echo 'Help I can't proceed'" does in a shell script.
Hmm, this sounds like a good idea...
Got any particular interfaces in mind?
>
> The big issues, are always about "security" as a starting point. And
> it's hard to manage security without some pre-established settings.
> What do we all think about a "default" security configuration (such as
> binding to localhost, asserting a download permission and using SSL)
> that fall out of the APIs (or new APIs) more naturally.
Yes definitely, perhaps we also need to provide an insecure alternative
also.
Java 2 security is difficult to understand, even when you author code,
you don't necessarily know what guards your method calls will end up
invoking. The biggest problem is developers don't define the
permissions their code needs and administrators don't know what to
specify in their policy files.
I've been working on ways to cut through the maze:
com.sun.jini.tool.DebugDynamicPolicy was designed to capture policy
security checks to assist developers to determine permissions required.
In addition we now have com.sun.jini.tool.ProfilingSecurityManager
(Original Author: Mark Petrovic BSD License)
Why do we need two tools?
DebugDynamicPolicy only tells you what permissions are required.
ProfilingSecurityManager tells you what permissions each jar requires,
it will also tell you permission checks made by static ProtectionDomain's.
Prior to Java 1.4, ProtectionDomain's were immutable, the policy was
only consulted at the time the ProtectionDomain was created, all
permissions were CodeSource based (static). Java 1.4 added dynamic
policy and principal based permission grants. Some of these old
"static" ProtectionDomain's still exist in code, so you need a
SecurityManager to capture their security checks, the policy will never
be consulted.
Something not well known is your SecurityManager and Policy should be
specified on the command line together at jvm startup. Due to out of
order optimisations, the point in time when a SecurityManager is loaded
(when called from your code) can differ by platform, leading some
platforms to require additional permissions, sometimes this will also
crop up when making subtle changes. This often happens with our qa test
suite, I do intend to fix it a some point.
Soon I intend to borrow some code from Apache Felix, allowing smart
proxy's to declare the permissions they require in their jar.
As I mentioned on the Security policy Service thread, OSGi uses a
permissions.perms file to describe a bundle's (jar file) local permissions.
The apache felix classes that parse this file are:
org.osgi.service.permissionadmin.PermissionInfo
org.apache.felix.framework.security.util.LocalPermissions
It appears pretty simple to make use of this file format with proven
code for retrieving permissions from jar files.
Developers can use ProfilingSecurityManager to determine what
permissions their proxy jar requires.
Then client's only need ask a proxy, what permissions it requires and if
acceptable, grant them, after authentication and proxy verification. If
unacceptable, the client can find another service instance.
>
> For example, the design of Configuration is great, except for the fact
> that you have to provide your own default values, and "property names"
> are random, so you have to engineer, yourself, something to "get it
> right" before you can get started (the startnow project's
> PersistentJiniService and ConfigurableApplication classes were aimed
> at trying to fill this void.
>
> It seems like we also could use a good desktop ServiceUI client that
> would provide good features out of the box to allow application
> development to be faster without so many "little bits" being required
> to get started.
>
> Thoughts?
Agree with all above.
Cheers,
Peter.
>
> Gregg Wonderly
>
>> On 2 August 2011 01:52, Peter Firmstone<ji...@zeus.net.au> wrote:
>>> Just get some feedback on this potential remote policy service. The
>>> main
>>> intent here is to provide a secure centralised policy administrator to
>>> simplify java security policy management for a djinn group. Note
>>> this is
>>> new work, so it doesn't yet support encrypted policy files.
>>>
>>> I've used code from Apache Harmony to parse standard syntax java policy
>>> files.
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>>>
>>> /*
>>> * Licensed to the Apache Software Foundation (ASF) under one
>>> * or more contributor license agreements. See the NOTICE file
>>> * distributed with this work for additional information
>>> * regarding copyright ownership. The ASF licenses this file
>>> * to you under the Apache License, Version 2.0 (the
>>> * "License"); you may not use this file except in compliance
>>> * with the License. You may obtain a copy of the License at
>>> *
>>> * http://www.apache.org/licenses/LICENSE-2.0
>>> *
>>> * Unless required by applicable law or agreed to in writing, software
>>> * distributed under the License is distributed on an "AS IS" BASIS,
>>> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>>> implied.
>>> * See the License for the specific language governing permissions and
>>> * limitations under the License.
>>> */
>>>
>>> package org.apache.river.api.security;
>>>
>>> import java.io.IOException;
>>> import net.jini.security.GrantPermission;
>>> import net.jini.security.policy.UmbrellaGrantPermission;
>>> import org.apache.river.impl.security.policy.util.PolicyParser;
>>> import org.apache.river.impl.security.policy.util.DefaultPolicyParser;
>>> import org.apache.river.impl.security.policy.util.DefaultPolicyScanner;
>>>
>>> /**
>>> * RemotePolicy is a service implemented by a Policy Provider, that
>>> allows
>>> * the java security Policy to be updated remotely by a djinn group
>>> administrator.
>>> *
>>> * For security purposes, only secure jeri Endpoint's should be used
>>> and must
>>> * require client and server authentication, in addition the proxy
>>> must be a
>>> * reflective proxy only, DownloadPermission should not be granted,
>>> which is
>>> * also beneficial to reduced network load at the administrator
>>> client. *
>>> RemotePolicy may be submitted to a lookup service, where an
>>> administrator
>>> * client will look it up and replace PermissionGrant's periodically.
>>> *
>>> * To reduce network load, the administrator client may delay updates by
>>> * lazily processing updates in a serial manner. New RemotePolicy
>>> services
>>> * obtained by the administrator client's via RemoteEvent
>>> notification should
>>> * be processed as a priority over policy updates. Eventually a
>>> djinn group
>>> * policy should reach equilibrium where all nodes have had their
>>> policy's
>>> * updated.
>>> *
>>> * This policy, in addition to any local policy provider, allows a
>>> network
>>> djinn
>>> * administrator to provide a list of PermissionGrant's, from a
>>> single or
>>> * replicated remote location, distributed to all nodes in a djinn
>>> group the
>>> * administrator is responsible for.
>>> *
>>> * In addition, replicating administrator clients may register a pseudo
>>> RemotePolicy
>>> * in order to track the primary administrator client and take over
>>> in the
>>> * event it fails. Failure may be failure to authenticate or failure to
>>> renew
>>> * a Lease.
>>> *
>>> * RemotePolicy, if it encapsulates an underlying RemotePolicy, does not
>>> * delegate updates to the base RemotePolicy, this is in case an
>>> * implementer wants a number of different layers of RemotePolicy, where
>>> * each layer represents a different administrator role or
>>> responsibility. *
>>> The administrator's subject must hold the necessary permissions in
>>> order
>>> * to grant them, including RuntimePermission("getProtectionDomain").
>>> *
>>> * A node may join more than one djinn group, in this case
>>> RemotePolicy's may
>>> * be used as nested basePolicy's.
>>> *
>>> * The intent of RemotePolicy is to simplify granting of
>>> DowloadPermission to
>>> * new signer Certificates and adding new Principals and Permission's to
>>> * distributed policy providers.
>>> *
>>> * Local policy files should be used to restrict the Permissions
>>> grantable
>>> * via a RemotePolicy.
>>> *
>>> * PermissionGrant's that are replaced and no longer exist in the
>>> RemotePolicy
>>> * will no longer be implied by the policy.
>>> *
>>> * DefaultPolicyParser has been provided for an administrator client to
>>> * parse standard java format policy file's, to create PermissionGrant's
>>> * custom policy file formats may be used by extending
>>> DefaultPolicyScanner.
>>> *
>>> * @author Peter Firmstone
>>> * @see GrantPermission
>>> * @see UmbrellaGrantPermission
>>> * @see PolicyParser
>>> * @see DefaultPolicyParser
>>> * @see DefaultPolicyScanner
>>> */
>>> public interface RemotePolicy {
>>> /**
>>> * Replaces the existing RemotePolicy's PermissionGrant's.
>>> *
>>> * The array is defensively copied, the caller, must have
>>> * RuntimePermission("getProtectionDomain")
>>> * as well as GrantPermission or UmbrellaGrantPermission for every
>>> * Permission granted by each PermissionGrant.
>>> *
>>> * In this case the caller will be the client Subject.
>>> *
>>> * These Permissions should be set in the local policy files at the
>>> * RemotePolicy server.
>>> *
>>> * @param policyPermissions
>>> * @throws java.io.IOException
>>> */
>>> public void replace(PermissionGrant[] policyPermissions) throws
>>> IOException;
>>> }
>>>
>>>
>
>
Re: Security [Was] Re: RemotePolicy service
Posted by Peter Firmstone <ji...@zeus.net.au>.
Dan Creswell wrote:
> Hi Peter,
>
> On 4 August 2011 03:43, Peter Firmstone <ji...@zeus.net.au> wrote:
>
>> Dan, you're wise and I respect your view.
>>
>>
>
> Thank you equally be careful how much wiseness you attribute to me and
> thus how much respect you give me - nobody is perfect! :)
>
>
>> Security matters to me because I plan to deploy over insecure networks.
>>
>>
>
> Yep, that's visible in your areas of focus in respect of River and
> given it's nasty stuff to play with I appreciate your focus.
>
>
>> Luckily security is mostly complete, Bob Scheifler's team achieved what they
>> set out to do, a very difficult task I might add. But this takes skill on
>> the application developers part to understand and utilise.
>>
>>
>
> Agreed.
>
>
>> For an application developer, determining policy files and permissions is
>> often one of the big hurdles.
>>
>>
>
> Agreed.
>
>
>> I get where you're coming from, deployment needs to be simpler and
>> installation / configuration needs to be automagic.
>>
>>
>
> Quite - a routine problem is the selection of an interface that does multicast.
>
Maybe we need a jira with a list of common difficulties experienced, so
we can pick them off one by one.
>
>> To make it possible to add in security later, requires the application
>> developer to follow certain rules and method calls. These are typically
>> very similar among different services.
>>
>>
>
> Absolutely.
>
>
>> I'm wondering if it's possible to use annotations to hide these methods from
>> the application developer on the client side, so they can learn to develop
>> without worrying about security, perhaps using only reflective proxy's to
>> start with, then activate security later and start using smart proxy's when
>> ready?
>>
>>
>
> Can I check I understand that annotations thing? I think you're saying
> that we'd use annotations on their code to identify methods we'd need
> to invoke for them or provide stub implementations for? Seems
> reasonable if that's the case.
>
Correct.
> I would say reflective proxy's are the easy starting point, although
> if we're doing the annotations thing, maybe we can make it work
> reasonably for smart proxies too. In fact, maybe annotations are a way
> to make things nicer for all regardless of level of expertise. I think
> we'd have to allow things to work without annotations (lots of code
> out there already written) but....
>
>
Now I must confess, I've quite happily used other peoples annotations,
but admit to never having defined any.
We've got the ASM library, we could use this as an annotation processor,
to weave in what people like to refer to as boilerplate code (well
bytecode actually).
Existing code missing the annotations, wouldn't be affected.
I guess a good place to start is to identify the snippets of code we
need to create, and what annotation types we should define.
>> Typically we're talking proxy verification, dynamic permission grant's,
>> running as Subjects, using key stores and using method constraints.
>>
>>
>
> Uh huh - I think the toughest of those for newbies are dynamic
> permission grants and proxy verification (at least in the smart proxy
> case), possibly Subjects too.
>
By using an annotation processor and including a permissions.perm file
in META-INF, we could weave in code that fetches the permissions from
the proxy jar and dynamically grants them, if the proxy is authenticated
and verified and provided the caller has the necessary
GrantPermissions. In this case the caller is the client Subject.
Since GrantPermission's are designed specifically for Dynamic grants,
there is an assumption that the client will grant these to proxy's it
can authenticate.
We could weave in the code that does proxy verification too. Then the
application developers only needs to work out how to run as a Subject.
The following questions remain:
1. Does the client Subject need to know the permissions it is about
to grant?
2. Is it an acceptable compromise to assume the client Subject is
prepared to grant these permissions to the proxy of any
authenticating service?
3. GrantPermission(AllPermission) would be a security risk.
4. The client Subject can have a wider scope of permissions than
those it has GrantPermission for, so it would be an administrator
choice what Permissions users can grant.
5. It's generally bad practise to ask the user directly if they want
to grant permission, they often mindlessly just say: "Yes! I want
to see the flying pig video!"
6. Do we need to retrieve the service's authenticating, Subject
retrieve its Principal's and use that information to make a
decision about the permissions the client's prepared to grant?
This sounds too fine grained to me. We probably want something
that works most of the time, is relatively secure.
7. Signed jar files can be used to restrict class loading with
DownloadPermission granted to signers, this improves security,
Authenticating the service and using proxy verification is a way
of saying, I can trust the code because I trust the authenticated
Service and it trusts the code. Signing the code is a way of
improving trust in the code, but it doesn't authenticate the
Service and the Service still needs to know if the proxy belongs
to it.
Cheers,
Peter.
Reference:
http://publib.boulder.ibm.com/infocenter/wasinfo/fep/index.jsp?topic=/com.ibm.websphere.osgifep.multiplatform.doc/topics/ca_java2sec.html
Java 2 security and OSGi Applications
You can use Java 2 security in OSGi applications in a similar way to
Java 2 security in Java EE applications. This topic describes the
differences when you use Java 2 security in an OSGi application.
The OSGi specifications allow you to have permissions.perm files in the
OSGI-INF directory of each bundle, so that you can apply fine-grained
control to the permissions for each bundle. The OSGi Applications
implementation in WebSphere® Application Server supports this
specification, and also allows you to have a permissions.perm file in
the META-INF directory of the OSGi application, which gives you
coarser-grained control of the permissions for the application as a whole.
A permissions.perm file is a plain text file that contains comments or
single-line permissions in the following form:
# Permissions file
( org.osgi.framework.AdminPermission "*" "*" )
( org.osgi.framework.PackagePermission "*" "exportonly,import" )
( org.osgi.framework.ServicePermission "*" "get,register")
( org.osgi.framework.BundlePermission "*" "host,provide,fragment")
Relation to Java EE applications and was.policy files
These application-level permissions.perm files perform a similar
function to was.policy files in enterprise applications. When you
migrate an application from Java EE to OSGi, any existing was.policy
file is converted into a permissions.perm file to be used with the OSGi
permissions framework.
In the conversion, any codebases specified within the was.policy file
are ignored, and all permissions specified are added to the
permissions.perm file. This means that all permissions are promoted to
the application level. If you need finer granularity, you can modify the
file after conversion. In this case, you would remove the required
permissions from the resulting permissions.perm file, and move them into
permission files within the OSGI-INF directory for each affected bundle.
>
>> Cheers,
>>
>> Peter.
>>
>>
>
> Two cents,
>
> Dan.
>
>
>> Dan Creswell wrote:
>>
>>> I recall Waldo saying some time ago that systems get harder and harder
>>> to do as you in order from:
>>>
>>> (1) Single-thread single machine.
>>> (2) Multi-thread single machine.
>>> (3) Multi-machine.
>>> (4) Multi-machine with security.
>>>
>>> On that basis, I'm tempted to say we should make our lives easier by
>>> setting something that limits the amount of heavy-lifting we need
>>> before we have anything to show for it/play with. Thus, I'd say we do,
>>> in order:
>>>
>>> (1) We should look at easing the admin burden - in terms of scooping
>>> up exceptions, logging, monitoring and such.
>>> (2) Sort out a bare bones out of the box experience - minimal configs,
>>> intelligent auto-setup for network interface selection.
>>> (3) Security for all the above.
>>>
>>> Now, I know and it's right to say on some levels, baking in security
>>> from the start often is what needs to be done but Jini itself managed
>>> without security early on and we probably ought to plan to "throw one
>>> away" (as per Mythical Man Month) as we figure these things out so I
>>> personally believe security can wait.
>>>
>>> +1 for doing as much through JMX as possible by default if that's
>>> practical (fear with multiple JVMs on one box a la simulating
>>> distributed services it might get tough).
>>>
>>>
>>
>
>
Re: Security [Was] Re: RemotePolicy service
Posted by Dan Creswell <da...@gmail.com>.
Hi Peter,
On 4 August 2011 03:43, Peter Firmstone <ji...@zeus.net.au> wrote:
> Dan, you're wise and I respect your view.
>
Thank you equally be careful how much wiseness you attribute to me and
thus how much respect you give me - nobody is perfect! :)
> Security matters to me because I plan to deploy over insecure networks.
>
Yep, that's visible in your areas of focus in respect of River and
given it's nasty stuff to play with I appreciate your focus.
> Luckily security is mostly complete, Bob Scheifler's team achieved what they
> set out to do, a very difficult task I might add. But this takes skill on
> the application developers part to understand and utilise.
>
Agreed.
> For an application developer, determining policy files and permissions is
> often one of the big hurdles.
>
Agreed.
> I get where you're coming from, deployment needs to be simpler and
> installation / configuration needs to be automagic.
>
Quite - a routine problem is the selection of an interface that does multicast.
> To make it possible to add in security later, requires the application
> developer to follow certain rules and method calls. These are typically
> very similar among different services.
>
Absolutely.
> I'm wondering if it's possible to use annotations to hide these methods from
> the application developer on the client side, so they can learn to develop
> without worrying about security, perhaps using only reflective proxy's to
> start with, then activate security later and start using smart proxy's when
> ready?
>
Can I check I understand that annotations thing? I think you're saying
that we'd use annotations on their code to identify methods we'd need
to invoke for them or provide stub implementations for? Seems
reasonable if that's the case.
I would say reflective proxy's are the easy starting point, although
if we're doing the annotations thing, maybe we can make it work
reasonably for smart proxies too. In fact, maybe annotations are a way
to make things nicer for all regardless of level of expertise. I think
we'd have to allow things to work without annotations (lots of code
out there already written) but....
> Typically we're talking proxy verification, dynamic permission grant's,
> running as Subjects, using key stores and using method constraints.
>
Uh huh - I think the toughest of those for newbies are dynamic
permission grants and proxy verification (at least in the smart proxy
case), possibly Subjects too.
> Cheers,
>
> Peter.
>
Two cents,
Dan.
>
> Dan Creswell wrote:
>>
>> I recall Waldo saying some time ago that systems get harder and harder
>> to do as you in order from:
>>
>> (1) Single-thread single machine.
>> (2) Multi-thread single machine.
>> (3) Multi-machine.
>> (4) Multi-machine with security.
>>
>> On that basis, I'm tempted to say we should make our lives easier by
>> setting something that limits the amount of heavy-lifting we need
>> before we have anything to show for it/play with. Thus, I'd say we do,
>> in order:
>>
>> (1) We should look at easing the admin burden - in terms of scooping
>> up exceptions, logging, monitoring and such.
>> (2) Sort out a bare bones out of the box experience - minimal configs,
>> intelligent auto-setup for network interface selection.
>> (3) Security for all the above.
>>
>> Now, I know and it's right to say on some levels, baking in security
>> from the start often is what needs to be done but Jini itself managed
>> without security early on and we probably ought to plan to "throw one
>> away" (as per Mythical Man Month) as we figure these things out so I
>> personally believe security can wait.
>>
>> +1 for doing as much through JMX as possible by default if that's
>> practical (fear with multiple JVMs on one box a la simulating
>> distributed services it might get tough).
>>
>
>
Security [Was] Re: RemotePolicy service
Posted by Peter Firmstone <ji...@zeus.net.au>.
Dan, you're wise and I respect your view.
Security matters to me because I plan to deploy over insecure networks.
Luckily security is mostly complete, Bob Scheifler's team achieved what
they set out to do, a very difficult task I might add. But this takes
skill on the application developers part to understand and utilise.
For an application developer, determining policy files and permissions
is often one of the big hurdles.
I get where you're coming from, deployment needs to be simpler and
installation / configuration needs to be automagic.
To make it possible to add in security later, requires the application
developer to follow certain rules and method calls. These are typically
very similar among different services.
I'm wondering if it's possible to use annotations to hide these methods
from the application developer on the client side, so they can learn to
develop without worrying about security, perhaps using only reflective
proxy's to start with, then activate security later and start using
smart proxy's when ready?
Typically we're talking proxy verification, dynamic permission grant's,
running as Subjects, using key stores and using method constraints.
Cheers,
Peter.
Dan Creswell wrote:
> I recall Waldo saying some time ago that systems get harder and harder
> to do as you in order from:
>
> (1) Single-thread single machine.
> (2) Multi-thread single machine.
> (3) Multi-machine.
> (4) Multi-machine with security.
>
> On that basis, I'm tempted to say we should make our lives easier by
> setting something that limits the amount of heavy-lifting we need
> before we have anything to show for it/play with. Thus, I'd say we do,
> in order:
>
> (1) We should look at easing the admin burden - in terms of scooping
> up exceptions, logging, monitoring and such.
> (2) Sort out a bare bones out of the box experience - minimal configs,
> intelligent auto-setup for network interface selection.
> (3) Security for all the above.
>
> Now, I know and it's right to say on some levels, baking in security
> from the start often is what needs to be done but Jini itself managed
> without security early on and we probably ought to plan to "throw one
> away" (as per Mythical Man Month) as we figure these things out so I
> personally believe security can wait.
>
> +1 for doing as much through JMX as possible by default if that's
> practical (fear with multiple JVMs on one box a la simulating
> distributed services it might get tough).
>
Re: RemotePolicy service
Posted by Gregg Wonderly <gr...@wonderly.org>.
On 8/3/2011 3:08 PM, Dan Creswell wrote:
> I recall Waldo saying some time ago that systems get harder and harder
> to do as you in order from:
>
> (1) Single-thread single machine.
> (2) Multi-thread single machine.
> (3) Multi-machine.
> (4) Multi-machine with security.
>
> On that basis, I'm tempted to say we should make our lives easier by
> setting something that limits the amount of heavy-lifting we need
> before we have anything to show for it/play with. Thus, I'd say we do,
> in order:
>
> (1) We should look at easing the admin burden - in terms of scooping
> up exceptions, logging, monitoring and such.
The thing that keeps coming to mind for me, is a visible list of "Exporter",
"Lease", "Transaction" and other "RemoteObject" instances. This could for
example be done through a "TrackedConfiguration" object that would provide a
place to attach JMX or just export it for tracking etc. Everything that
TrackedConfiguration returned could thus have lifecycle visibility as well as
other uses. Later, TrackedConfiguration could be removed from use too.
> (2) Sort out a bare bones out of the box experience - minimal configs,
> intelligent auto-setup for network interface selection.
Multiple interfaces on one machine is always "hard" to make "simple", but it's
possible to make reasonable guesses. The TrackedConfiguration class, would
actually need to have a higher level interface that would speak to the types of
objects being retrieved so that defaults could be provided.
As in this kind of business:
public abstract class TrackedConfiguration extends ConfigurationFile {
public abstract Exporter getExporterEntry(
String component, String name );
public abstract Endpoint getSSLEndpointEntry(
String component, String name );
public abstract Endpoint getTcpEndpointEntry(
String component, String name );
public abstract ProxyPreparer getPreparerEntry(
String component, String name );
public abstract List<Exporter> activeExporters();
public abstract List<Endpoint> activeEndpoints();
public abstract List<ProxyPreparer> activePreparers();
public abstract List<Remote> activeRemoteObjects();
}
> (3) Security for all the above.
You might then imagine it being a pretty high level sync interface for a few
other things, such as turning on default security doing things like:
public void setRequiresSSL(boolean how);
public void setRequiresSubject( Subject sub );
public void setRequiresPrincipal( Principal prin );
public void setRequiresPermissionForRemoteCode(
boolean how, PermissionCollection perms );
> Now, I know and it's right to say on some levels, baking in security
> from the start often is what needs to be done but Jini itself managed
> without security early on and we probably ought to plan to "throw one
> away" (as per Mythical Man Month) as we figure these things out so I
> personally believe security can wait.
What I want to try and achieve is to demonstrate that security is not a barrier,
but a convenient necessity. This would be the number one issue, for me to vote
on addressing the simplification thereof.
> +1 for doing as much through JMX as possible by default if that's
> practical (fear with multiple JVMs on one box a la simulating
> distributed services it might get tough).
The com.sun.jini.start mechanism, is what I use all the time now. It's
something that we should try and work on to make it easier to "add services" to.
As I've said before, I have a version of that code that includes a drag-n-drop
desktop deployment interface that would allow us to package the River services
into something that people could deploy trivially and visibly to always get it
"right". There services would need to be built with a specific packaging
mechanism, and I have not "finished" that.
What I did was put together a "jar in a jar" jar: protocol handling support so
that a deployed service could easily be matched with the exact versions of the
platform it was built with so that file systems get out of view for deployment.
Making this happen with maven now, might make a lot of sense.
Gregg
> On 3 August 2011 20:48, Gregg Wonderly<gr...@gmail.com> wrote:
>> On 8/2/2011 3:15 AM, Dan Creswell wrote:
>>>
>>> How will an administrator know when their djinn has reached equilibrium?
>>>
>>> Answer: Probably by observation rather than providing a guaranteed time
>>> period.
>>>
>>> Next question: Do your interfaces support the administrator need to
>>> understand their djinn's behaviour?
>>
>> This is where I think there is a giant "hole" in management for Jini. We
>> could provide something through JMX (with a jini connector perhaps) as a
>> "use what others might have" mechanism. But, in the end, it seems like we
>> really need to have a "local service" that is automatically secured that
>> services connect to and announce state, exceptions etc. That local service
>> would be the one with a JMX interface I think. Basically, I still find
>> boot-strapping services to be frustratingly prolonged because there's so
>> much "initial" stuff that has to be "right" before something "sane" happens.
>> If we could standardize such a "local service" and it's interface, then we
>> might be able to at least provide generic tooling that would make a lot of
>> things "just work". In the end, that "local service" should feel as easy to
>> use as "echo 'Help I can't proceed'" does in a shell script.
>>
>> The big issues, are always about "security" as a starting point. And it's
>> hard to manage security without some pre-established settings. What do we
>> all think about a "default" security configuration (such as binding to
>> localhost, asserting a download permission and using SSL) that fall out of
>> the APIs (or new APIs) more naturally.
>>
>> For example, the design of Configuration is great, except for the fact that
>> you have to provide your own default values, and "property names" are
>> random, so you have to engineer, yourself, something to "get it right"
>> before you can get started (the startnow project's PersistentJiniService and
>> ConfigurableApplication classes were aimed at trying to fill this void.
>>
>> It seems like we also could use a good desktop ServiceUI client that would
>> provide good features out of the box to allow application development to be
>> faster without so many "little bits" being required to get started.
>>
>> Thoughts?
>>
>> Gregg Wonderly
>>
>>> On 2 August 2011 01:52, Peter Firmstone<ji...@zeus.net.au> wrote:
>>>>
>>>> Just get some feedback on this potential remote policy service. The main
>>>> intent here is to provide a secure centralised policy administrator to
>>>> simplify java security policy management for a djinn group. Note this is
>>>> new work, so it doesn't yet support encrypted policy files.
>>>>
>>>> I've used code from Apache Harmony to parse standard syntax java policy
>>>> files.
>>>>
>>>> Cheers,
>>>>
>>>> Peter.
>>>>
>>>>
>>>> /*
>>>> * Licensed to the Apache Software Foundation (ASF) under one
>>>> * or more contributor license agreements. See the NOTICE file
>>>> * distributed with this work for additional information
>>>> * regarding copyright ownership. The ASF licenses this file
>>>> * to you under the Apache License, Version 2.0 (the
>>>> * "License"); you may not use this file except in compliance
>>>> * with the License. You may obtain a copy of the License at
>>>> *
>>>> * http://www.apache.org/licenses/LICENSE-2.0
>>>> *
>>>> * Unless required by applicable law or agreed to in writing, software
>>>> * distributed under the License is distributed on an "AS IS" BASIS,
>>>> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>>>> implied.
>>>> * See the License for the specific language governing permissions and
>>>> * limitations under the License.
>>>> */
>>>>
>>>> package org.apache.river.api.security;
>>>>
>>>> import java.io.IOException;
>>>> import net.jini.security.GrantPermission;
>>>> import net.jini.security.policy.UmbrellaGrantPermission;
>>>> import org.apache.river.impl.security.policy.util.PolicyParser;
>>>> import org.apache.river.impl.security.policy.util.DefaultPolicyParser;
>>>> import org.apache.river.impl.security.policy.util.DefaultPolicyScanner;
>>>>
>>>> /**
>>>> * RemotePolicy is a service implemented by a Policy Provider, that allows
>>>> * the java security Policy to be updated remotely by a djinn group
>>>> administrator.
>>>> *
>>>> * For security purposes, only secure jeri Endpoint's should be used and
>>>> must
>>>> * require client and server authentication, in addition the proxy must be
>>>> a
>>>> * reflective proxy only, DownloadPermission should not be granted, which
>>>> is
>>>> * also beneficial to reduced network load at the administrator client. *
>>>> RemotePolicy may be submitted to a lookup service, where an administrator
>>>> * client will look it up and replace PermissionGrant's periodically.
>>>> *
>>>> * To reduce network load, the administrator client may delay updates by
>>>> * lazily processing updates in a serial manner. New RemotePolicy
>>>> services
>>>> * obtained by the administrator client's via RemoteEvent notification
>>>> should
>>>> * be processed as a priority over policy updates. Eventually a djinn
>>>> group
>>>> * policy should reach equilibrium where all nodes have had their policy's
>>>> * updated.
>>>> *
>>>> * This policy, in addition to any local policy provider, allows a network
>>>> djinn
>>>> * administrator to provide a list of PermissionGrant's, from a single or
>>>> * replicated remote location, distributed to all nodes in a djinn group
>>>> the
>>>> * administrator is responsible for.
>>>> *
>>>> * In addition, replicating administrator clients may register a pseudo
>>>> RemotePolicy
>>>> * in order to track the primary administrator client and take over in the
>>>> * event it fails. Failure may be failure to authenticate or failure to
>>>> renew
>>>> * a Lease.
>>>> *
>>>> * RemotePolicy, if it encapsulates an underlying RemotePolicy, does not
>>>> * delegate updates to the base RemotePolicy, this is in case an
>>>> * implementer wants a number of different layers of RemotePolicy, where
>>>> * each layer represents a different administrator role or responsibility.
>>>> *
>>>> The administrator's subject must hold the necessary permissions in order
>>>> * to grant them, including RuntimePermission("getProtectionDomain").
>>>> *
>>>> * A node may join more than one djinn group, in this case RemotePolicy's
>>>> may
>>>> * be used as nested basePolicy's.
>>>> *
>>>> * The intent of RemotePolicy is to simplify granting of DowloadPermission
>>>> to
>>>> * new signer Certificates and adding new Principals and Permission's to
>>>> * distributed policy providers.
>>>> *
>>>> * Local policy files should be used to restrict the Permissions grantable
>>>> * via a RemotePolicy.
>>>> *
>>>> * PermissionGrant's that are replaced and no longer exist in the
>>>> RemotePolicy
>>>> * will no longer be implied by the policy.
>>>> *
>>>> * DefaultPolicyParser has been provided for an administrator client to
>>>> * parse standard java format policy file's, to create PermissionGrant's
>>>> * custom policy file formats may be used by extending
>>>> DefaultPolicyScanner.
>>>> *
>>>> * @author Peter Firmstone
>>>> * @see GrantPermission
>>>> * @see UmbrellaGrantPermission
>>>> * @see PolicyParser
>>>> * @see DefaultPolicyParser
>>>> * @see DefaultPolicyScanner
>>>> */
>>>> public interface RemotePolicy {
>>>> /**
>>>> * Replaces the existing RemotePolicy's PermissionGrant's.
>>>> *
>>>> * The array is defensively copied, the caller, must have
>>>> * RuntimePermission("getProtectionDomain")
>>>> * as well as GrantPermission or UmbrellaGrantPermission for every
>>>> * Permission granted by each PermissionGrant.
>>>> *
>>>> * In this case the caller will be the client Subject.
>>>> *
>>>> * These Permissions should be set in the local policy files at the
>>>> * RemotePolicy server.
>>>> *
>>>> * @param policyPermissions
>>>> * @throws java.io.IOException
>>>> */
>>>> public void replace(PermissionGrant[] policyPermissions) throws
>>>> IOException;
>>>> }
>>>>
>>>>
>>
>>
>
Re: RemotePolicy service
Posted by Dan Creswell <da...@gmail.com>.
I recall Waldo saying some time ago that systems get harder and harder
to do as you in order from:
(1) Single-thread single machine.
(2) Multi-thread single machine.
(3) Multi-machine.
(4) Multi-machine with security.
On that basis, I'm tempted to say we should make our lives easier by
setting something that limits the amount of heavy-lifting we need
before we have anything to show for it/play with. Thus, I'd say we do,
in order:
(1) We should look at easing the admin burden - in terms of scooping
up exceptions, logging, monitoring and such.
(2) Sort out a bare bones out of the box experience - minimal configs,
intelligent auto-setup for network interface selection.
(3) Security for all the above.
Now, I know and it's right to say on some levels, baking in security
from the start often is what needs to be done but Jini itself managed
without security early on and we probably ought to plan to "throw one
away" (as per Mythical Man Month) as we figure these things out so I
personally believe security can wait.
+1 for doing as much through JMX as possible by default if that's
practical (fear with multiple JVMs on one box a la simulating
distributed services it might get tough).
On 3 August 2011 20:48, Gregg Wonderly <gr...@gmail.com> wrote:
> On 8/2/2011 3:15 AM, Dan Creswell wrote:
>>
>> How will an administrator know when their djinn has reached equilibrium?
>>
>> Answer: Probably by observation rather than providing a guaranteed time
>> period.
>>
>> Next question: Do your interfaces support the administrator need to
>> understand their djinn's behaviour?
>
> This is where I think there is a giant "hole" in management for Jini. We
> could provide something through JMX (with a jini connector perhaps) as a
> "use what others might have" mechanism. But, in the end, it seems like we
> really need to have a "local service" that is automatically secured that
> services connect to and announce state, exceptions etc. That local service
> would be the one with a JMX interface I think. Basically, I still find
> boot-strapping services to be frustratingly prolonged because there's so
> much "initial" stuff that has to be "right" before something "sane" happens.
> If we could standardize such a "local service" and it's interface, then we
> might be able to at least provide generic tooling that would make a lot of
> things "just work". In the end, that "local service" should feel as easy to
> use as "echo 'Help I can't proceed'" does in a shell script.
>
> The big issues, are always about "security" as a starting point. And it's
> hard to manage security without some pre-established settings. What do we
> all think about a "default" security configuration (such as binding to
> localhost, asserting a download permission and using SSL) that fall out of
> the APIs (or new APIs) more naturally.
>
> For example, the design of Configuration is great, except for the fact that
> you have to provide your own default values, and "property names" are
> random, so you have to engineer, yourself, something to "get it right"
> before you can get started (the startnow project's PersistentJiniService and
> ConfigurableApplication classes were aimed at trying to fill this void.
>
> It seems like we also could use a good desktop ServiceUI client that would
> provide good features out of the box to allow application development to be
> faster without so many "little bits" being required to get started.
>
> Thoughts?
>
> Gregg Wonderly
>
>> On 2 August 2011 01:52, Peter Firmstone<ji...@zeus.net.au> wrote:
>>>
>>> Just get some feedback on this potential remote policy service. The main
>>> intent here is to provide a secure centralised policy administrator to
>>> simplify java security policy management for a djinn group. Note this is
>>> new work, so it doesn't yet support encrypted policy files.
>>>
>>> I've used code from Apache Harmony to parse standard syntax java policy
>>> files.
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>>>
>>> /*
>>> * Licensed to the Apache Software Foundation (ASF) under one
>>> * or more contributor license agreements. See the NOTICE file
>>> * distributed with this work for additional information
>>> * regarding copyright ownership. The ASF licenses this file
>>> * to you under the Apache License, Version 2.0 (the
>>> * "License"); you may not use this file except in compliance
>>> * with the License. You may obtain a copy of the License at
>>> *
>>> * http://www.apache.org/licenses/LICENSE-2.0
>>> *
>>> * Unless required by applicable law or agreed to in writing, software
>>> * distributed under the License is distributed on an "AS IS" BASIS,
>>> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
>>> implied.
>>> * See the License for the specific language governing permissions and
>>> * limitations under the License.
>>> */
>>>
>>> package org.apache.river.api.security;
>>>
>>> import java.io.IOException;
>>> import net.jini.security.GrantPermission;
>>> import net.jini.security.policy.UmbrellaGrantPermission;
>>> import org.apache.river.impl.security.policy.util.PolicyParser;
>>> import org.apache.river.impl.security.policy.util.DefaultPolicyParser;
>>> import org.apache.river.impl.security.policy.util.DefaultPolicyScanner;
>>>
>>> /**
>>> * RemotePolicy is a service implemented by a Policy Provider, that allows
>>> * the java security Policy to be updated remotely by a djinn group
>>> administrator.
>>> *
>>> * For security purposes, only secure jeri Endpoint's should be used and
>>> must
>>> * require client and server authentication, in addition the proxy must be
>>> a
>>> * reflective proxy only, DownloadPermission should not be granted, which
>>> is
>>> * also beneficial to reduced network load at the administrator client. *
>>> RemotePolicy may be submitted to a lookup service, where an administrator
>>> * client will look it up and replace PermissionGrant's periodically.
>>> *
>>> * To reduce network load, the administrator client may delay updates by
>>> * lazily processing updates in a serial manner. New RemotePolicy
>>> services
>>> * obtained by the administrator client's via RemoteEvent notification
>>> should
>>> * be processed as a priority over policy updates. Eventually a djinn
>>> group
>>> * policy should reach equilibrium where all nodes have had their policy's
>>> * updated.
>>> *
>>> * This policy, in addition to any local policy provider, allows a network
>>> djinn
>>> * administrator to provide a list of PermissionGrant's, from a single or
>>> * replicated remote location, distributed to all nodes in a djinn group
>>> the
>>> * administrator is responsible for.
>>> *
>>> * In addition, replicating administrator clients may register a pseudo
>>> RemotePolicy
>>> * in order to track the primary administrator client and take over in the
>>> * event it fails. Failure may be failure to authenticate or failure to
>>> renew
>>> * a Lease.
>>> *
>>> * RemotePolicy, if it encapsulates an underlying RemotePolicy, does not
>>> * delegate updates to the base RemotePolicy, this is in case an
>>> * implementer wants a number of different layers of RemotePolicy, where
>>> * each layer represents a different administrator role or responsibility.
>>> *
>>> The administrator's subject must hold the necessary permissions in order
>>> * to grant them, including RuntimePermission("getProtectionDomain").
>>> *
>>> * A node may join more than one djinn group, in this case RemotePolicy's
>>> may
>>> * be used as nested basePolicy's.
>>> *
>>> * The intent of RemotePolicy is to simplify granting of DowloadPermission
>>> to
>>> * new signer Certificates and adding new Principals and Permission's to
>>> * distributed policy providers.
>>> *
>>> * Local policy files should be used to restrict the Permissions grantable
>>> * via a RemotePolicy.
>>> *
>>> * PermissionGrant's that are replaced and no longer exist in the
>>> RemotePolicy
>>> * will no longer be implied by the policy.
>>> *
>>> * DefaultPolicyParser has been provided for an administrator client to
>>> * parse standard java format policy file's, to create PermissionGrant's
>>> * custom policy file formats may be used by extending
>>> DefaultPolicyScanner.
>>> *
>>> * @author Peter Firmstone
>>> * @see GrantPermission
>>> * @see UmbrellaGrantPermission
>>> * @see PolicyParser
>>> * @see DefaultPolicyParser
>>> * @see DefaultPolicyScanner
>>> */
>>> public interface RemotePolicy {
>>> /**
>>> * Replaces the existing RemotePolicy's PermissionGrant's.
>>> *
>>> * The array is defensively copied, the caller, must have
>>> * RuntimePermission("getProtectionDomain")
>>> * as well as GrantPermission or UmbrellaGrantPermission for every
>>> * Permission granted by each PermissionGrant.
>>> *
>>> * In this case the caller will be the client Subject.
>>> *
>>> * These Permissions should be set in the local policy files at the
>>> * RemotePolicy server.
>>> *
>>> * @param policyPermissions
>>> * @throws java.io.IOException
>>> */
>>> public void replace(PermissionGrant[] policyPermissions) throws
>>> IOException;
>>> }
>>>
>>>
>
>
Re: RemotePolicy service
Posted by Gregg Wonderly <gr...@gmail.com>.
On 8/2/2011 3:15 AM, Dan Creswell wrote:
> How will an administrator know when their djinn has reached equilibrium?
>
> Answer: Probably by observation rather than providing a guaranteed time period.
>
> Next question: Do your interfaces support the administrator need to
> understand their djinn's behaviour?
This is where I think there is a giant "hole" in management for Jini. We could
provide something through JMX (with a jini connector perhaps) as a "use what
others might have" mechanism. But, in the end, it seems like we really need to
have a "local service" that is automatically secured that services connect to
and announce state, exceptions etc. That local service would be the one with a
JMX interface I think. Basically, I still find boot-strapping services to be
frustratingly prolonged because there's so much "initial" stuff that has to be
"right" before something "sane" happens. If we could standardize such a "local
service" and it's interface, then we might be able to at least provide generic
tooling that would make a lot of things "just work". In the end, that "local
service" should feel as easy to use as "echo 'Help I can't proceed'" does in a
shell script.
The big issues, are always about "security" as a starting point. And it's hard
to manage security without some pre-established settings. What do we all think
about a "default" security configuration (such as binding to localhost,
asserting a download permission and using SSL) that fall out of the APIs (or new
APIs) more naturally.
For example, the design of Configuration is great, except for the fact that you
have to provide your own default values, and "property names" are random, so you
have to engineer, yourself, something to "get it right" before you can get
started (the startnow project's PersistentJiniService and
ConfigurableApplication classes were aimed at trying to fill this void.
It seems like we also could use a good desktop ServiceUI client that would
provide good features out of the box to allow application development to be
faster without so many "little bits" being required to get started.
Thoughts?
Gregg Wonderly
> On 2 August 2011 01:52, Peter Firmstone<ji...@zeus.net.au> wrote:
>> Just get some feedback on this potential remote policy service. The main
>> intent here is to provide a secure centralised policy administrator to
>> simplify java security policy management for a djinn group. Note this is
>> new work, so it doesn't yet support encrypted policy files.
>>
>> I've used code from Apache Harmony to parse standard syntax java policy
>> files.
>>
>> Cheers,
>>
>> Peter.
>>
>>
>> /*
>> * Licensed to the Apache Software Foundation (ASF) under one
>> * or more contributor license agreements. See the NOTICE file
>> * distributed with this work for additional information
>> * regarding copyright ownership. The ASF licenses this file
>> * to you under the Apache License, Version 2.0 (the
>> * "License"); you may not use this file except in compliance
>> * with the License. You may obtain a copy of the License at
>> *
>> * http://www.apache.org/licenses/LICENSE-2.0
>> *
>> * Unless required by applicable law or agreed to in writing, software
>> * distributed under the License is distributed on an "AS IS" BASIS,
>> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
>> * See the License for the specific language governing permissions and
>> * limitations under the License.
>> */
>>
>> package org.apache.river.api.security;
>>
>> import java.io.IOException;
>> import net.jini.security.GrantPermission;
>> import net.jini.security.policy.UmbrellaGrantPermission;
>> import org.apache.river.impl.security.policy.util.PolicyParser;
>> import org.apache.river.impl.security.policy.util.DefaultPolicyParser;
>> import org.apache.river.impl.security.policy.util.DefaultPolicyScanner;
>>
>> /**
>> * RemotePolicy is a service implemented by a Policy Provider, that allows
>> * the java security Policy to be updated remotely by a djinn group
>> administrator.
>> *
>> * For security purposes, only secure jeri Endpoint's should be used and must
>> * require client and server authentication, in addition the proxy must be a
>> * reflective proxy only, DownloadPermission should not be granted, which is
>> * also beneficial to reduced network load at the administrator client. *
>> RemotePolicy may be submitted to a lookup service, where an administrator
>> * client will look it up and replace PermissionGrant's periodically.
>> *
>> * To reduce network load, the administrator client may delay updates by
>> * lazily processing updates in a serial manner. New RemotePolicy services
>> * obtained by the administrator client's via RemoteEvent notification should
>> * be processed as a priority over policy updates. Eventually a djinn group
>> * policy should reach equilibrium where all nodes have had their policy's
>> * updated.
>> *
>> * This policy, in addition to any local policy provider, allows a network
>> djinn
>> * administrator to provide a list of PermissionGrant's, from a single or
>> * replicated remote location, distributed to all nodes in a djinn group the
>> * administrator is responsible for.
>> *
>> * In addition, replicating administrator clients may register a pseudo
>> RemotePolicy
>> * in order to track the primary administrator client and take over in the
>> * event it fails. Failure may be failure to authenticate or failure to
>> renew
>> * a Lease.
>> *
>> * RemotePolicy, if it encapsulates an underlying RemotePolicy, does not
>> * delegate updates to the base RemotePolicy, this is in case an
>> * implementer wants a number of different layers of RemotePolicy, where
>> * each layer represents a different administrator role or responsibility. *
>> The administrator's subject must hold the necessary permissions in order
>> * to grant them, including RuntimePermission("getProtectionDomain").
>> *
>> * A node may join more than one djinn group, in this case RemotePolicy's may
>> * be used as nested basePolicy's.
>> *
>> * The intent of RemotePolicy is to simplify granting of DowloadPermission to
>> * new signer Certificates and adding new Principals and Permission's to
>> * distributed policy providers.
>> *
>> * Local policy files should be used to restrict the Permissions grantable
>> * via a RemotePolicy.
>> *
>> * PermissionGrant's that are replaced and no longer exist in the
>> RemotePolicy
>> * will no longer be implied by the policy.
>> *
>> * DefaultPolicyParser has been provided for an administrator client to
>> * parse standard java format policy file's, to create PermissionGrant's
>> * custom policy file formats may be used by extending DefaultPolicyScanner.
>> *
>> * @author Peter Firmstone
>> * @see GrantPermission
>> * @see UmbrellaGrantPermission
>> * @see PolicyParser
>> * @see DefaultPolicyParser
>> * @see DefaultPolicyScanner
>> */
>> public interface RemotePolicy {
>> /**
>> * Replaces the existing RemotePolicy's PermissionGrant's.
>> *
>> * The array is defensively copied, the caller, must have
>> * RuntimePermission("getProtectionDomain")
>> * as well as GrantPermission or UmbrellaGrantPermission for every
>> * Permission granted by each PermissionGrant.
>> *
>> * In this case the caller will be the client Subject.
>> *
>> * These Permissions should be set in the local policy files at the
>> * RemotePolicy server.
>> *
>> * @param policyPermissions
>> * @throws java.io.IOException
>> */
>> public void replace(PermissionGrant[] policyPermissions) throws
>> IOException;
>> }
>>
>>
Re: RemotePolicy service
Posted by Dan Creswell <da...@gmail.com>.
How will an administrator know when their djinn has reached equilibrium?
Answer: Probably by observation rather than providing a guaranteed time period.
Next question: Do your interfaces support the administrator need to
understand their djinn's behaviour?
On 2 August 2011 01:52, Peter Firmstone <ji...@zeus.net.au> wrote:
> Just get some feedback on this potential remote policy service. The main
> intent here is to provide a secure centralised policy administrator to
> simplify java security policy management for a djinn group. Note this is
> new work, so it doesn't yet support encrypted policy files.
>
> I've used code from Apache Harmony to parse standard syntax java policy
> files.
>
> Cheers,
>
> Peter.
>
>
> /*
> * Licensed to the Apache Software Foundation (ASF) under one
> * or more contributor license agreements. See the NOTICE file
> * distributed with this work for additional information
> * regarding copyright ownership. The ASF licenses this file
> * to you under the Apache License, Version 2.0 (the
> * "License"); you may not use this file except in compliance
> * with the License. You may obtain a copy of the License at
> *
> * http://www.apache.org/licenses/LICENSE-2.0
> *
> * Unless required by applicable law or agreed to in writing, software
> * distributed under the License is distributed on an "AS IS" BASIS,
> * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
> * See the License for the specific language governing permissions and
> * limitations under the License.
> */
>
> package org.apache.river.api.security;
>
> import java.io.IOException;
> import net.jini.security.GrantPermission;
> import net.jini.security.policy.UmbrellaGrantPermission;
> import org.apache.river.impl.security.policy.util.PolicyParser;
> import org.apache.river.impl.security.policy.util.DefaultPolicyParser;
> import org.apache.river.impl.security.policy.util.DefaultPolicyScanner;
>
> /**
> * RemotePolicy is a service implemented by a Policy Provider, that allows
> * the java security Policy to be updated remotely by a djinn group
> administrator.
> *
> * For security purposes, only secure jeri Endpoint's should be used and must
> * require client and server authentication, in addition the proxy must be a
> * reflective proxy only, DownloadPermission should not be granted, which is
> * also beneficial to reduced network load at the administrator client. *
> RemotePolicy may be submitted to a lookup service, where an administrator
> * client will look it up and replace PermissionGrant's periodically.
> *
> * To reduce network load, the administrator client may delay updates by
> * lazily processing updates in a serial manner. New RemotePolicy services
> * obtained by the administrator client's via RemoteEvent notification should
> * be processed as a priority over policy updates. Eventually a djinn group
> * policy should reach equilibrium where all nodes have had their policy's
> * updated.
> *
> * This policy, in addition to any local policy provider, allows a network
> djinn
> * administrator to provide a list of PermissionGrant's, from a single or
> * replicated remote location, distributed to all nodes in a djinn group the
> * administrator is responsible for.
> *
> * In addition, replicating administrator clients may register a pseudo
> RemotePolicy
> * in order to track the primary administrator client and take over in the
> * event it fails. Failure may be failure to authenticate or failure to
> renew
> * a Lease.
> *
> * RemotePolicy, if it encapsulates an underlying RemotePolicy, does not
> * delegate updates to the base RemotePolicy, this is in case an
> * implementer wants a number of different layers of RemotePolicy, where
> * each layer represents a different administrator role or responsibility. *
> The administrator's subject must hold the necessary permissions in order
> * to grant them, including RuntimePermission("getProtectionDomain").
> *
> * A node may join more than one djinn group, in this case RemotePolicy's may
> * be used as nested basePolicy's.
> *
> * The intent of RemotePolicy is to simplify granting of DowloadPermission to
> * new signer Certificates and adding new Principals and Permission's to
> * distributed policy providers.
> *
> * Local policy files should be used to restrict the Permissions grantable
> * via a RemotePolicy.
> *
> * PermissionGrant's that are replaced and no longer exist in the
> RemotePolicy
> * will no longer be implied by the policy.
> *
> * DefaultPolicyParser has been provided for an administrator client to
> * parse standard java format policy file's, to create PermissionGrant's
> * custom policy file formats may be used by extending DefaultPolicyScanner.
> *
> * @author Peter Firmstone
> * @see GrantPermission
> * @see UmbrellaGrantPermission
> * @see PolicyParser
> * @see DefaultPolicyParser
> * @see DefaultPolicyScanner
> */
> public interface RemotePolicy {
> /**
> * Replaces the existing RemotePolicy's PermissionGrant's.
> *
> * The array is defensively copied, the caller, must have
> * RuntimePermission("getProtectionDomain")
> * as well as GrantPermission or UmbrellaGrantPermission for every
> * Permission granted by each PermissionGrant.
> *
> * In this case the caller will be the client Subject.
> *
> * These Permissions should be set in the local policy files at the
> * RemotePolicy server.
> *
> * @param policyPermissions
> * @throws java.io.IOException
> */
> public void replace(PermissionGrant[] policyPermissions) throws
> IOException;
> }
>
>