Hi everyone, after starting to examine the OSGi spec with respect to security, I came across a few questions, I'd like to address here. I have to apologize for the length of the mail, but I wasn't able to capture it accurately in a shorter version.
The specification states: "If security checks are performed, they must be done according to Java 2 Security Architecture. "[p.21] and "The conditional permissions provide a very general model that is related to, but different from the Java 2 Policy model."[p.235]. Does this mean; conditions are an add-on mechanism or a replacement for Java Policies? I actually would expect it to be an add-on in order to be "according to the Java 2 Security Architecture", but there is space to argue. Of course I thought about this question… One can argue that conditional based security provides everything you need. You can use standard Java 2 permissions to define rules and you can use custom as well as OSGi permissions. Conditions can capture CodeSource equivalent filter mechanisms like location information or provided certificates - so far so good. Unfortunately, in my point of view there is one major drawback. The OSGi spec lacks a static or better initial configuration file determine what are the startup permissions. In a simple scenario f.i., I only have a framework deployed with Security enabled. Who is now allowed to grant right to new bundles? Of course, I can deploy a bundle, which is using the ConditionalPermissionAdmin Service and sets up everything. But who grants this bundle all the rights it needs. If you run the framework, first allowing everyone to do everything is obviously against Java Policies in terms of the least privilege idiom/ principle even though you can set the start order of bundles. So I would actually expect Java policies to be used and mapped to OSGi Conditions in the Permission Class. Ok, till now this is all pretty much theoretical and conceptual discussion about taste, but what about Security and Application Servers? You can't just run a J2EE server with "allow everything", if you want to deploy a single OSGi FW based WebApplication among a dozen others. Eventually you will need to provide a valid ProtectionDomain object, which can handle Java policies provided to your server. Thus, the ClassLoaders each OSGi FW uses to load its bundles need to provide a PD where plain Java policies can be applied. Otherwise the default policies take place with no CodeSource information, which would mean applying permissions to everyone if you define Java permissions without a destinct source or certificate. (I am excluding the problem of Principal or the (most likely) not settable SecurityManager in this environment, but that has to be taken into account as well.) Well, what I am trying to say here is that there is no description at all in the spec, how the policy model in plain Java and the conditional model in OSGi should work together. I think this should be pointed out to some extend, no matter what the advice will be. For me it would be interesting to see, what others think about that. Maybe I am missing something. Not sure. Another point, which I found strange, is the handling of signatures. On the one hand the spec states: "A Framework therefore must refuse to run a bundle when a signature does not match the contents or it does not recognize the signer." [p.230 section: 9.2.2], but it doesn't care at all, if it is not signed. So if I sign my bundle with a random or even verified signature, as long as it is not in my Keystore, the framework will reject it, but if I don't sign it at all, it can be run. I think there should be a flag or some sort of management API allowing only signed bundles to be installed in order to offer an advantage of this rejection mechanism. In Java, there is unfortunately no standard way of rejecting any code from installation in general. Only the permissions granted to this code are limited. Even if this protects the environment from most attack scenarios, denial of service attacks are still very simple to implement. Just create an infinite loop and allocate memory. Eventually your JVM will crash. If you managed to exploit other things first, you might even be able to prevent the ConditionalPermissionAdmin configuration bundle from starting, which eventually shuts down your entire security mechanisms. So I guess in OSGi such a more strict mechanism might be a good idea. As a last point, "Figure 9.39 System, Local and Security permissions" [p. 224] headline talks about "Security permissions", but I don't actually know what these should be in distinction to System and Local ones (they both are derived from java.security.Permission). In the according chapter "Security permissions" are never mentioned at all. I assume, "Security permissions" can just be left away, because it doesn't provide any additional information. I am not a security expert, so if I got something wrong, please feel free to correct me. As always, feedback is greatly appreciated. Thanks, Mirko _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
