Hi All,
On Thu, Nov 21, 2013 at 1:18 PM, Ben Koppenaal <[email protected]>wrote: > On Thu, Nov 14, 2013 at 10:51 AM, Alexander Broekhuis < > [email protected] > > wrote: > > > Hi, > > > > Just my thoughts for this topic. > > > > 2013/11/14 <[email protected]> > > > > > > > What is the best way to implement security features (e.g. signed > > bundles) > > > > into Celix? > > > > - include it as a linked library? > > > > - put it directly into the framework? > > > > - or create a security bundle, but make sure it loads first? > > > > > > What are the advantages and disadvantages of the options? Would for > > > example having a bundle give the option to reuse parts of the security > > > bundle to do data encryption? > > > > > > > > I don't expect the same functionality to be used elsewhere. > > > > > Per option: > > * Linked library: > > Benefit: Inherent part of the framework, security is always available. > > Drawback: Additional dependencies (ssl etc). > > * Directly into the framework: Same as with a library. > > * Bundle: > > Benefit: Can be enabled/disabled > > Drawback: Should be loaded first, Celix doesn't have StartLevel > support, > > and I doubt this is a good usecase for it... > > > > Some more info. At first I thought Java OSGi solely relies on Java's own > > mechanisms. But this isn't the case. The OSGi specification states that > is > > has a more restricted usage, ie normally Jars can be signed partially, > OSGi > > doesn't allow this. > > So looking into how Felix solved it; They use a bundle, but not a normal > > bundle. Security is deployed in an extension bundle. Extension bundles > are > > detailed in the spec and state that the framework has to be restarted > when > > an extension is installed/updated/removed. > > > > What does this mean for Celix? At the moment Celix doesn't support > > Extension bundles because there is no code sharing support. So for now > > having security in a bundle doesn't make sense. Also seeing that an > > Extension Bundles extends the Framework, a linked library might make more > > sense. > > But, directly linking with a library creates additional dependencies, so > a > > better solution would be to use a library and at startup check if it is > > available and load the library and its symbols only then. This gives the > > user flexibility wrt compilation/linking and in usage. > > > > > The last solution sounds like the best one; it has my vote. It is a good > combination of security and flexibility. > I think putting the signed bundles functionality in a library is a good idea. I don't agree with dynamically checking if the library exists. I prefer a compilation option, which if turn on requires the library (e.g. has a dependency to), this is IMO a more simple approach. This also enforces that a securtiy library is needed when Celix is compiled with this option, which is IMO a more secure. > > > > > > > > > > Concerning activation and configuration: > > > > - include a configuration option to (de)activate the requirement of > > > signed > > > > bundles? > > > > - choose whether or not signed bundles are required prior to > > compilation, > > > > such that it becomes an always on/off feature? > > > > > > > From a security standpoint I see several options: > > * No security at all: For example disabling the security option in the > > build because of missing dependencies > > * Required: Security is available and should be used. This means all > > bundles being installed MUST be signed and validated. > > * Optional: Security is available and can be used. This means that > bundles > > with signing information are validated, others are just installed. > > > > As for where these options should be? > > a) Having an option gives more freedom > > b) But having an option might give to much freedom, build-in is more > > secure. > > > > So I think it can be a build option without the need for configuration > > * Build-options: Security Required/Security Optional/Security Disabled > > Required implies always on, everything must be signed > > Optional implies that signed bundles are verified > > Disabled implies that signing information is simply ignored > > > > > > > > > > I think having the option to toggle the requirement after compilation > > > would be nice to have because it allows you to compile the framework > once > > > and use it on multiple systems. > > > > > > > Considering this, I think a sane default would be the Optional build > > settings. If really needed an additional configuration option could be > used > > to make it required via configuration. > > > > Wdyt? > > > > I agree that a build option would the best solution and choosing the > optional one as the default setting. > > Other than that I don't have anything useful to add at the moment. If > anything pops into my mind I'll reply again, but until then I'd say that it > should be implemented as an library with a check at start-up to see if it's > available. And with the three options you listed with the optional one as > default. > +1 for the build option. But what about the options: required, configurable and disabled. Where: - required means : bundles need to be signed and securty library is mandatory. - configurable means : security library is mandatory, but whether bundles needs to be signed, are only checked if signed or no checking at all is a configuration option (config.properties). - disabled means: security libary is not used and bundles will not be checked. > > > > > > -- > > Met vriendelijke groet, > > > > Alexander Broekhuis > > >
