Hi Tom, sounds good. Hope the R4.2 is coming soon ;-)
Well, concerning you're question, you're right. I am waiting for the "INSTALLED" event to get a notification about newly introduced bundles. Assuming I have a secure runtime, no other bundle will have the right to resolve that bundle other than my agent. After checking the certificates the build-in pseudo rule-engine decides what to do with the bundle... continue resolving or uninstalling it. Do you see any problems with this approach or do you have a better idea? I thought an installed bundle is still pretty safe, because it doesn't have a class loader, it can't be used as a library for resource lookups and native code isn't loaded as well. Just the meta-data is known to the framework, which shouldn't hurt I hope. Another alternative approach I was thinking about was having the management agent control the whole installation process. Meaning the framework starts with just one single bundle (the MA) and after the start, a configuration is read, which defines the certificate rules, start order,etc. in order to boot-up the whole system. However I preferred the other solution because of obvious reasons. I don't want to invent/implement everything from scratch. I thought this should be a not so unusual use case (although security isn't used that excessively), so I assumed the spec reflects it somehow. Any insights on how such things are done right now (in academia as well as industry) are more than welcome. Thanks, Mirko -- Mirko Jahn http://osgi.mjahn.net On Thu, Dec 11, 2008 at 3:31 PM, Thomas Watson <[EMAIL PROTECTED]> wrote: > For the OSGi R4.2 specification there is a proposal to add a new method to > Bundle to get the signer certificates. I think this would help out your > scenario. But I am wandering how a synchronous bundle listener is going to > prevent the installation of a bundle if the user chooses not to trust the > bundle. There is no INSTALLING event, only INSTALLED event. This means the > bundle has already been installed and is available. Would you then simply > uninstall the bundle at that point? > > Tom > > > > "Mirko Jahn" ---12/11/2008 07:44:45 AM---Hey there, > > > From: > "Mirko Jahn" <[EMAIL PROTECTED]> > To: > "OSGi Developer Mail List" <osgi-dev@mail.osgi.org> > Date: > 12/11/2008 07:44 AM > Subject: > [osgi-dev] Certificate access in Management Agent > ________________________________ > > > Hey there, > > I am currently working on a general management agent for security. I > have a somewhat working prototype, but it lacks several key features I > was hoping to integrate. Most importantly, I wonna get rid of all > proprietary code and that's the reason why am asking. The management > agent (MA) gets installed first. At that time, no other bundle is > installed yet. I have a synchronous bundle listener to get notified > about attempts to install any further bundles and to asses if they > should be installed or not. Now I am asking myself... > > - How could one get access to the ProtectionDomain information of a > bundle from within the MA? Things like the signer, the certificates, > etc. I don't have a Class or ClassLoader at hand to get this kind of > information. I also don't have access to the jar to extract these kind > of information manually. > - Same is true for a custom Condition. How can I gain access to the > ProtectionDomain information within that one? > - As an alternative, I thought about using the BundleSignerCondition, > but here I am very limited in my syntax of expressing a dependency on > the certificate chain (simply f.i.: A -> B -> C vs. A -> X -> B` -> > C`, here a test for trust root A - like VerySign - and properties of C > will also be valid for both cases, because the C` appears identical to > C, but differs in the chain). Maybe I am wrong, but I don't know > exactly how to express such constraints. (see 4.1 spec 2.3.6) > > Thanks, > Mirko > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > > _______________________________________________ > OSGi Developer Mail List > osgi-dev@mail.osgi.org > https://mail.osgi.org/mailman/listinfo/osgi-dev > _______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
