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<[email protected]>  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;
}





Reply via email to