Only Core must be permitted to consume the Storage service

[jri]

In particular in conjunction with #835 a plugin could access the DeepaMehtaStorage? service directly and thus bypass access control as implemented in Core. Accessing the storage must be a privilege of Core.

To realize that we could choose among these approaches:

• Make module deepamehta-storage-neo4j just a library which provides no OSGi service.
• Secure storage service access by the means of a org.osgi.framework.ServicePermission.

[jri]

• Secure storage service access by the means of a org.osgi.framework.ServicePermission.

I decided to choose that approach as it is more "OSGi-like", and I want use the opportunity to learn more about both, Java security, and OSGi security (which builds on-top-of Java security). After reading a crucial amount of information I understand that there is no suitable solution (at least in Felix). Damn.

The OSGi way to go is the "Conditional Permission Admin" service as part of the OSGi Core platform (and provided by Felix as a separate module: "Apache Felix Framework Security"). It allows to change the OSGi security policy conditionally and dynamically. E.g. you can programmatically formulate this rule: deny the permission to get hold of the DeepaMehtaStorage service for all bundles which are not the de.deepamehta.core bundle (as identified by the bundle's location). That sound's great.

Then the question arises who should setup that policy? The first guess is: the DM Core bundle. In its Activator it would get hold of the Conditional Permission Admin service and add that rule. BUT (you guess it): every bundle could get hold of the Conditional Permission Admin service as well and establish contrary rules and even DENY the Core to use the Conditional Permission Admin service at all. So we've a race condition here.

To solve that 2 approaches come into mind:

• Use OSGi Start Levels: start the Core at a lower level than all other bundles. It would then start first and thus have the exclusive opportunity to setup the security policy for all other bundles.

However I don't want go that way. Using start levels never felt right to me, kind of a "not OSGi-like" hack. Furthermore, there is no guarantee the start levels are enforced in every possibly OSGi deployment situation. Just consider hot deployment via Felix File Install vs. the framework launcher's auto-deploy feature vs. installing via Gogo shell vs. using "install feature" in an existing Karaf environment. Using Start Levels are just a too brittle concept to build such an important aspect as security upon it.

• Let the OSGi Framework Launcher (org.apache.felix.main in our case) establish the security policy. It would do so just after instantiating the framework and before any other bundles are started. It could do so e.g. by reading a system property which points to a OSGi security policy file (analogous to java.security.policy for Java security). OSGi even defines a file format for policy files (which extends and is incompatible with the Java policy format), and the OSGi security API provides constructors for processing that format. BUT (2 obstacles):

1) The Felix framework launcher just don't do that. It does not read an OSGi security policy file at startup. It does not provide such a system property. So we have no possibility to let the launcher pass a security policy to the framework instance.

A possible solution would be to build our own launcher. But honestly: I don't want do that. This is the launcher's (org.apache.felix.main) job and it would be fairly easy for its developers to implement that.

2) In case of deployment via "install feature" in an existing Karaf environment that OSGi security policy file would not be processed without manual configuration (and restarting?) the Karaf environment. I wonder how useful Karaf's "install feature" feature actually is, if the feature to be installed has no opportunity to change the Karaf configuration during the course. But this concern might be owed to my limited Karaf knowledge.

So, at the moment I see no reasonable approach to safely realize the org.osgi.framework.ServicePermission.

I wish someone could help conceptual-wise.
dgf in particular :-)

​http://securesoftwaredev.com/2012/11/19/permissions-in-osgi/
​http://www.moi.vonos.net/java/osgi-security/
​http://felix.apache.org/documentation/subprojects/apache-felix-framework-security.html
​http://felix.apache.org/documentation/subprojects/apache-felix-framework/apache-felix-framework-configuration-properties.html
​http://apache-felix.18485.x6.nabble.com/OSGI-Security-in-Felix-td5010083.html
​http://osgi.org/javadoc/r5/core/index.html?org/osgi/service/condpermadmin/package-summary.html
​http://docs.oracle.com/javase/7/docs/technotes/guides/security/PolicyFiles.html