An implementation of the OSGi Permission Admin

Copyright 2004 TRIALOG

Disclaimer

This bundle is meant to handle the SECURITY of YOUR FRAMEWORK.

If I were you, I wouldn't use it without a minute review of its source. And this shouldn't be that difficult since it is a really small bundle, completely separated from the framework implementation.

Licenses

OSGi Permission Admin

This implementation by Trialog of the OSGi Permission Admin service is licensed 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.

KXML & XML Pull

The Permission Admin implementation relies on kXML and XML Pull, which have their own licenses, available at the root of the bundle sources.

Installation

Given the implementation of the java.security.Policy.setPolicy method, the Permissions granted to the PermissionAdminPolicy are determined by the previous security Policy (most likely sun's default policy).

So, in order for the Permission Admin to work, you need to define permissions “outside of itself”, even if there is absolutely no permission defined within OSGi (which results in AllPermission for all bundles).

grant codeBase "file:../bundle/permissionadmin.jar" {

permission org.osgi.framework.AdminPermission;

permission org.osgi.framework.ServicePermission "org.osgi.service.permissionadmin.PermissionAdmin", "register";

permission java.security.SecurityPermission "setPolicy";

};

On the other hand, all the permissions set before starting the PA will be lost. As an improvement, it shall be possible to import the previous permissions if no save file is found.

Files of the project

• The embedded folder contains the Java library(ies) to be embedded in the bundle.
• The lib folder contains other Java library(ies) that are needed by the compiler but that will not be embedded in the bundle.
• The src folder contains the Java classes of the Permission Admin implementation. Details of the classes is available in the Architecture section.
• Example.policy contains a sample Java policy to be used to start the Permission Admin within the Oscar OSGi framework.
• license-* contains the licenses of the included software.
• manifest.mf is the manifest file to be included in the bundle.

Architecture

You will find here a brief introduction to the architecture of this implementation of the Permission Admin service. For further details please refer to the Javadoc or directly to the source.

PermissionAdminActivator

This is the OSGi activator of the bundle. It creates an instance of the PermissionAdmin implementation and registers it in the service registry. When stopped, it triggers saving the permissions.

PermissionAdminImpl

It implements the PermissionAdmin interface, as defined by OSGi.

As of J2SE 1.4, the java.security.Policy class caches the permissions used by the implies method. So there is no need to implement another cache in this bundle.

PermissionInfo can be considered immutable since all the fields used by this class are private and the getters are final. So simply using the clone() method on the PermissionInfo array should suffice to ensure that no side-effect could occur.

PermissionAdminPolicy

It defines a security policy based on the PermissionInfos owned by the Permission Admin.

Logger

It is a utility class in charge of printing logs to the console.

XmlHandler

it is used to parse the permissions saved as an XML file and to save the permissions into a file.

OSGi Compliance

There is one point of the OSGi standard that this implementation is not complying with and will never be: The Permission Admin is provided as a bundle while the standard states it shall be integrated into the framework.

To Do List

1. The previous Policy instance could be saved and given to this implementation.

2. Check the behavior of this bundle when it is updated.

3. Find a way to "modify" the java.security.Policy cache. This cache must be invalidated when permissions are changed or if new Permission classes are made available to the framework.

4. Handle UnresolvedPermission: The policy shall listen to bundle events to update its PermissionCollection-s when a new, missing Permission is installed. And the other way round, when a bundle is removed.

5. Previous Policy should be used to get additional Permissions and return all

6. Using the LogService (when available) would be nice. Unfortunately, since the PermissionAdmin is most likely started before everything else, nothing is available, not even the LogService interface. It is also likely that the ServiceTracker class should also be emulated.