incubator-celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ben Koppenaal <>
Subject Re: Implementing security features in Celix
Date Thu, 21 Nov 2013 12:18:29 GMT
On Thu, Nov 14, 2013 at 10:51 AM, Alexander Broekhuis <
> wrote:

> Hi,
> Just my thoughts for this topic.
> 2013/11/14 <>
> >
> > > 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.

> >
> > > 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

> --
> Met vriendelijke groet,
> Alexander Broekhuis

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message