Mailing-List: contact celix-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: celix-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of a.broekhuis@gmail.com
 designates 209.85.128.51 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <bf38a66af02c64fedacd1f13e4eb15b4.squirrel@ghdev.nl>
References: 
 <CAEca9yH_yej+9SmwaAHZ8XoCjh7p6RQt8+JJ9obseHWqswO=8Q@mail.gmail.com>
	<bf38a66af02c64fedacd1f13e4eb15b4.squirrel@ghdev.nl>
Date: Thu, 14 Nov 2013 10:51:12 +0100
Message-ID: 
 <CA+T-u8dqeL+OXiA-_FqmNe2mCufzToBeKCv8n2q3yyAo3MHP-w@mail.gmail.com>
Subject: Re: Implementing security features in Celix
From: Alexander Broekhuis <a.broekhuis@gmail.com>
To: celix-dev@incubator.apache.org
Content-Type: multipart/alternative; boundary=047d7bdc17849e9d8804eb200587

--047d7bdc17849e9d8804eb200587
Content-Type: text/plain; charset=ISO-8859-1

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

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.


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

-- 
Met vriendelijke groet,

Alexander Broekhuis

--047d7bdc17849e9d8804eb200587--