On Monday 28 January 2008 21:13, Mirko Jahn wrote: Disclaimer; I am not very good with security.
> 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? AFAIUI, it is not possible for OSGi to "turn off" the standard Java security mechanism, so that can be applied outside, BUT that could be done in a way which forces the framework and/or its bundles not to work. > 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. It is an implementation detail, since OSGi does not enforce how or where the framework is run, it is near impossible to dictate how the initial security is established. > I only have a framework deployed with Security enabled. Who is now > allowed to grant right to new bundles? The framework is. If you notice, the Permission related services are "Core spec" as it is expected that these are exposed by the framework itself and not provided by loading bundles (or at least such bundle is tightly integrated into the particular framework implementation it is meant to run with). Again, it is an implementation detail on how a framework does this. > 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. I agree that one should be able to specify with a standard property to reject bundles and code that is not signed. I have not checked whether this exist or not, but take your word for it. > 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. No, (see above) this service is expected to be part of the framework itself, or very tightly integrated. I am sure others can provide more exhaustive answers. Cheers -- Niclas Hedhman, Software Developer I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
