I’ve spent the last couple of hours trying to understand Java2 Security in an OSGi environment. There’s a presentation available at [link] which gave me lots of information and hints of what to search for and what to play with. I’ve also had a quick skim to the relevant section of the OSGi 4.2 spec. Here’s a quick summary of what I’ve discovered. It may not be 100% correct… do let me know if i’ve got the wrong end of the stick on something.
In an OSGi 4.2 environment, the Conditional Permission Service is king. Well… kindof. There are 3 sources of permission information to consider:
1. Java2 Security Policy
2. Dynamic(Programmatic) configuration of the Conditional Permission Service
3. Local Permissions. (Static, per bundle policy)
In a relatively static environment it appears that you could pretty much ignore the programmatic Conditional Permission Service and rely on the more static options 1 and 3.
In order to enable OSGi security, you start by enabling Java2 security with an ‘all permissions’ policy file. Yes, I did just say that. It seems counter intuitive, but in order to allow the OSGi Framework to do its thing, it needs full permissions. It seems to be plausible to give just the framework bundle(s) the All Permission in the policy, but this affects (removes) the implied permissions of the other bundles which breaks everything. More investigation required.
So, assuming you already have an OSGi application:
java -jar org.eclipse.osgi_3.6.0.v20100517.jar -Djava.security.manager -Djava.security.policy=all.policy
all.policy:
grant { permission java.security.AllPermission; };
And you’re in an identical situation to before. All code has all permissions. The up side is that it’s just a couple of steps to start restricting the priviledges of your bundles.
Add an empty file “OSGI-INF/permissions.perm” to a bundle, and apart from some implict permissions (e.g. to import packages, read/write the bundle configuration area), that bundle has had its permissions entirely removed. You can the start giving the bundle permissions e.g. by adding a line:
(java.io.FilePermission “/Users/*” “read”)
This provides a very simple way to enumerate the permissions a bundle requires and restrict it to them. It also provides a simple file to audit for each bundle. There are a couple of important things to note:
1. An empty file is not equivalent to no permissions.perm file. Make sure you have a permissions.perm file if you want restricted permissions.
2. The permissions.perm file specifies the maximum permissions the bundle requires. The framework/Conditional Permission Service in conjunction with the system security policy may result in lower available permissions.
This looks great for reducing the risks from exploits in bundles I develop, but clearly doesn’t help much with 3rd party bundles, which is where the Conditional Permission Service should come into its own. More on that once I’ve worked it through.