<quote> 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… </quote>
I think you might be confusing the security architecture with the Policy model and Default Policy. We use the Java 2 Security Architecture to implement ConditionalPermissionAdmin. (We have to, Java 2 Security is a rather intrinsic part of the JVM.) The Java 2 Default Policy is implemented with a static file that encodes a specific policy. It is certainly not the only way of encoding Policy, it's the default. It's not even the best way. Especially the absence of scoping introduced in OSGi makes it hard to use signatures and still get least privilege unless you explode the number of signatures and you do a lot of manual policy tweaking. For CPA we needed a dynamic policy, we aren't going to restart things when the policy changes, and we needed to be flexible with are assignment criteria. <quote> 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. </quote> No, the principle of least privilege says you only get the privileges you need. The initial bundle is going to setup the permissions to all other bundles, so it must have, in effect, AllPermission. Perhaps you just want a standard way of specifying the initial config file. Is that it? As you point out, CPA has a superset of the functionality of the Default Policy file, we just don't say where it is stored. (I'm sure you realize that once you use CPA to change the permissions it is persistently stored, so this whole discussion is just about the what happens when you start the framework for the first time with no policy set. The general idea is the next bundle you install would be the bundle to setup the permissions at which point the discussion is over.) <quote> 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. </quote> Again you are referring to the default Java policy, which can be replaced in the normal case. The bootclasses startup with this policy. The CPA manages the policy of the classes loaded by OSGi. <quote> 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. </quote> You can assign permissions to bundles based on something other than signatures, so we don't require bundles to be signed. If a bundle is signed, but the contents don't match the signature, it has obviously been tampered with, so it seems obvious that it should not be used: the packager purposely signed it and it was changed after packaging. I think a case can be made for using a bundle that is signed by an unknown signer, but we erred on the side of safety. <quote> ... 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. </quote> No, CPA is a framework service. It is always active. It hooks right into class loading. It does not get started or shutdown. The service is just a view into the framework. ben _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
