celix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pepijn Noltes <pepijnnol...@gmail.com>
Subject Re: Implementing security features in Celix
Date Fri, 22 Nov 2013 08:39:29 GMT
Hi All,



On Thu, Nov 21, 2013 at 1:18 PM, Ben Koppenaal <ben.koppenaal@gmail.com>wrote:

> On Thu, Nov 14, 2013 at 10:51 AM, Alexander Broekhuis <
> a.broekhuis@gmail.com
> > wrote:
>
> > Hi,
> >
> > Just my thoughts for this topic.
> >
> > 2013/11/14 <erik@jansman.eu>
> > >
> > > > 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
> >
>

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