Hi BJ, thanks for your clarification, although I don't really like it, because it leaves the described problem with application servers and security. After policy files are not considered for security checks, I assume setting a trust store is also completely up to the vendor and the default Java trust store is ignored (please correct me if I am wrong).
> In the OSGi model, a bundle's ProtectionDomain is created based only upon > consulting the ConditionalPermissionAdmin (or PermissionAdmin if CPA is > not present). No policy file is used. So, in effect, the policy for > establishing a bundle's permissions is described in the database of > permission information managed via CPA. Ok, I get it, in that particular case we explicitly don't have any (backwards) compatibility in terms of policies. > A policy file may be used to set the permissions of the framework itself > since that is implementation specific and the class loader which loads the > framework may likely consult a policy file. most likely, yes. > So to bootstrap this situation, an empty CPA database will grant all > bundles AllPermission. So the very first bundles will have AllPermission, > It can then call CPA and alter the default permissions to a more > restrictive set. For example based upon signer. Note, that whatever bundle > will be calling CPA to manage the permission of bundles must itself have > AllPermission. It is futile to expect it to only require less permission, > since this bundle can modify its own permissions to have AllPermission :-) Using AllPermissions instead of a pseudo limited set of permissions is certainly easier and more precisely what the real security situation is like. My only point here was to show that in contrast to Peters note that initially there has to be an open environment (instead of a limited set of privileges), which allows to set permissions for everyone. To be honest, this is the part I don't like (conceptually, practical it is certainly doable). Java usually promotes the "least privilege principle" and this is clearly against that one. Fortunately the Start Level Service is not optional, although it doesn't define any static configuration file, which means, there is no way according to the spec (as far as I know) how to configure the start order of the bundles in your container for the first time. All vendors I know of have implemented something like that of course, but for me it sounds weird that it is not possible to create a secure environment just according to the spec. I think it is important for further versions of the spec to point out that the initial state of the FW is unsafe until a custom bundle is deployed, which sets the right permissions and that the start order is crucial to ensure a not compromised environment. Currently I am working on a security evaluation/certification and I would have loved just to point to specifications and mention vendors only as implementors. Now, after I understand the mechanism, I realize that I also have to evaluate their mechanisms to enforce real security on the system, because this will surely not be tested during the certification of the vendors to a satisfying extend. Anyway, thanks a lot for your clarification! Best Regards, Mirko > -- > > BJ Hargrave > Senior Technical Staff Member, IBM > OSGi Fellow and CTO of the OSGi Alliance > [EMAIL PROTECTED] > > office: +1 386 848 1781 > mobile: +1 386 848 3788 > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > http://www2.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List [email protected] http://www2.osgi.org/mailman/listinfo/osgi-dev
