Hi Ben, you made some good points. I realized that I indeed have to be a bit more specific on the scope I am looking at the spec right now.
Let's assume you are creating a device, which is running J2SE, so you can deploy anything you want there. In fact, it is not anything, but an OSGi framework. So further more there is an application A running inside of the container. This is the state you deliver it to your customers. However, time doesn't stand still and you want to provide let's say add-on features your customers should be able to buy/get after your device is delivered. So far no problem with OSGi, actually it is extremely nice. The problem occurs when you include external requirements, such as the Application A has to be certified against very specific and strong security requirements. You have to provide a separation on application level, which is static (in order to be evaluated) and can't be tampered with. So if the customer has the box, there mustn't be a chance to circumvent the defined security policies for this device, no matter what happens. Java Policies, although not that expressive as CPA are a good way to at least provide the the first bundle with a Permission to set conditions for the environment I thought. The OSGi spec, as far as I can tell, pretty much focuses on running the framework and here I don't see any problems from my perspective. The Problems I see are only related to the description on how to set up the first initial (really) safe environment. Java defines initial policies, which provide a basis set of permissions, which define the initial Sandbox. Starting from here you can gradually add permissions on an as needed basis until you reach your satisfying permission set. Despite the default permission everyone has, only permissions you explicitly added are granted to CodeSources/ProtectionDomains. Now, considering all the replies, in OSGi this is different and important to know about. Here the initial state is "open" unless a custom bundle is deployed, which sets the Permissions as needed. This setting of permissions is a little tricky, I think. Plain Java doesn't provide a deny statement, but this is actually something you need here. In my opinion not intuitively, but you can work around this by applying <null> for the condition(s) and (not sure) <null> for the permission(s) (or your own custom NoPermission permission) in CPA, but I think this should be mentioned in order to show the parallels to plain Java. Actually an AllBundleCondition together with a NoPermission permission would be nice to indicate the scope directly. Well, I understand that in theory everything is possible, but I was just hoping OSGi being more Security enforcing. After having thought about the issues, I could imagine a scenario, where OSGi first only allows the access to the CPA and as soon as a bundle uses the CPA, these management rights are bound to only this bundle. Now, this bundle can do what ever it wants in contrast to the others. The only plus here is, that unless something unsafe is defined, the FW is safe by default. Well, this is just a sample, one doesn't need anything like that to provide security of course, but reading the spec right now, without having this conversation makes it hard (at least for me) to fully understand the implications derived from the deviations of the Java default behavior. That's all. So this was my view with my Architect hat on, with security evaluator hat, it becomes more complicated. Java is a well recognized standard and so the effort to evaluate its security architecture is relatively simple, because many things can be taken as granted. OSGi however with its own Permission handling and the dynamism provides an additional layer, which introduces new (potential) threats and weaknesses. Here every lack in detail have to be evaluated for every implementation, which makes swapping of frameworks hard and more important expensive. As a typical sample of a implementation issue... A implementor can decide to cache/safe installed bundles together with other stuff in its "proprietary" way in order to safe state and other information. If someone now tries to manipulate these information, the framework has to have a mechanism to detect those manipulations, I think, but I never read it anywhere... Anyway, now I have a way better understanding of the OSGi way, so you guys already helped me a lot! Thanks for that. I added some comments on the last replies, some repeat what I already said in different words, sorry for the length. Best Regards, Mirko <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> Well, as part of the initial provisioning, I would consider policies important in the Security Architecture. Of course the Sun-way of defining policies is an implementation detail and surely not the best in every scenario - I know, but the internal handling/ representation is located in java.security.Policy class so, I think this is a good indicator to consider it a part of the Javas Security Architecture. And again, yes the file is static, but the Policy class itself has the capabilities to update its policies. Don't get me wrong on this one, I prefer the flexibility offered by OSGi, I was just trying to say that the Policies are the "natural" way in Java to provide some initial security provisioning and that this part (no matter how it is handled in OSGi) is left out completely in the spec. For me, coming from plain Java Security., it wasn't easy to figure out what "compatible with the Java 2 Security Architecture" actually involves. Currently, I am not interested in the dynamic capabilities of the OSGi Security Architecture, because we just can't use it in our scenario. What we need is a way to define a secure environment from startup, which can't be tempered with. <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> Correct. I am just looking on the very first startup. <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> You are right and I really like this behavior, but I think, this alone is not enough - it gives a false idea of security - if someone tampers with the bundle and knows about this behavior, the easy workaround is just removing the signature. Of course, this will most likely change the conditions under which the previous rights were granted, I know. The problem I see here is that if you are not aware of the fact that bundles without a signature are allowed by default (and if no special conditions are applied) are granted AllPermission can create a serious security hole. For a holistic view on security I would at least mention that in this particular context. <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. </quote> Well, I thought so, but for some strange reasons, I first manged to set up the server in a wrong way (I guess). As a result I got this message: org.osgi.framework.BundleException: ConditionalPermissionAdminService not available. Stop. This is fixed now, so don't worry about this, but maybe you understand now, how my questions were motivated. A service (no matter how thin) is another abstraction, which can be miss configured, miss used, etc.. I was/am just trying to find a way to set my initial environment as secure as possible in a standardized way. <quote> It would be relatively easy to write an initial bundle that reads the default java policy file and populates the CPA that way, but I would think in general you want a policy that depends on the specific deployment or application rather than the Java install. (This is especially true when you are running multiple OSGi instances on the same machine.) </quote> If you are talking about multiple JVMs you can just provide your custom policy file, extending the default one. If you are talking about one JVM it becomes nasty, here you really have only one Scope, where potentially mutliple policy files contribute to, so it is a mess to seperate the different issues (although possible). <quote> I'm not sure why you are talking about the StartLevelService. Is it because you didn't realize that the changes to policy done through the CPA are made persistent by the framework? </quote> Well, who defines, which is the first bundle to load on a box you don't have access to (except for the initial configuration)? I don't run it even once (or at least I don't want to be forced to!). SLS also doesn't have a specification for a config file (again, everything is runtime focused and service based), but all vendors implement their own way of defining it - not nice, if you ask me, but I can life with it. _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
