You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Andrew Scully <an...@gmail.com> on 2014/10/06 12:13:45 UTC
OSGI Security in Felix
Hello,
I'm looking into domain security in OSGI. I've assembled a fairly complete
picture of what this would involve, but I have a question which I would
appreciate your thoughts on. It would also be useful to me to check that I
have correctly understood so far.
To reiterate what I think I know (please correct if wrong!):
-I understand that setting permissions for the OSGI framework is something
that must be done programatically using the ConditionalPermissionAdmin
service. This is installed into Felix by an extension bundle.
-A file format is specified for defining permissions declaratively, but no
facility exists to automatically read a file in this format and bootstrap
the policy into the framework during startup (as you can with standard Java
security policies using a -D argument).
-You can implement your own service for reading in such a file and passing
the instructions to the ConditionalPermissionAdmin. Example code for this is
given in the "OSGI in Action" book, which I have seen.
Now here's my question!
As noted in both in OSGI in Action and in this post --
http://apache-felix.18485.x6.nabble.com/Felix-security-td4837010.html -- the
first bundle to "get" the ConditionalPermissionAdmin service effectively
controls the security for the entire framework, as it can change the
permissions to prevent others from changing permissions.
Obviously this is undesirable. The developer trying to secure the runtime
environment will want to ensure that the correct policy is applied without
the possibility of interference.
Furthermore, timing seems important. Surely, if a developer is trying to
prevent certain bundles from being installed, it would be no good if Felix
had already installed those bundles before the "security policy reader"
service had completed?
Therefore my question is this: Is it possible for a developer to guarantee
that their security policy is applied and is being enforced before the
framework starts "proper"?
To put that another way: If I implemented a bundle that read in an OSGI
security policy file and applied these settings to the framework (and then
locked it down preventing any further changes), how would I make sure that
this bundle ran "first"? Ideally, initialization of the rest of the
framework would be postponed until after this bundle had finished its work.
Any help hugely appreciated -- it feels like I'm just missing some small
step here!
Cheers, Andy.
--
View this message in context: http://apache-felix.18485.x6.nabble.com/OSGI-Security-in-Felix-tp5010083.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OSGI Security in Felix
Posted by Andrew Scully <an...@gmail.com>.
The latter option (doing this within the launcher) sounds like the more
robust approach (also we try and avoid using start levels) so I'll pursue
this angle.
Only problem is that the framework in our case is started by Glassfish, so
it looks like I have a bit more investigation to do!
BTW I can't help but think it would be a huge selling point for Felix if it
had a way to do this for you (you just dropped a file into a directory and
it applied the security policy automatically before locking things down)?
I would thank you, but there is a yellow banner at the top my screen warning
me that this would be a breach of mailing list etiquette!
--
View this message in context: http://apache-felix.18485.x6.nabble.com/OSGI-Security-in-Felix-tp5010083p5010089.html
Sent from the Apache Felix - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Dependency Manager: registering FrameworkListener
Posted by Bulu <bu...@romandie.com>.
There were two things I had in mind.
1. Has OSGi been expanded to handle it's own listeners with the
whiteboard pattern? The original paper "Listeners considered harmful..."
is from 2001, so maybe in these 13 years they have adopted it themselves...
My main problem here was: how should I google that (if I don't find
anything, is it because I don't know how to google or because it's not
there?). You clarified that point.
2. Using DM, I was wondering if there is an elegant way to add the
listener, in particular at the place where you define the component, but
I only came up with the following (see below) which I thought, was a bit
of a hack. As I'm pretty new in DM, I was wondering if I had overlooked
a clean way of doing the registration. You clarified that point as well.
mgr.add(createComponent()
.setImplementation(MyFrameworkListener.class)
.setCallbacks(new Object(){ // create callback object
public void start(Component c){
BundleContext bc =
c.getDependencyManager().getBundleContext();
bc.addFrameworkListener((FrameworkListener)
c.getService());
}
public void stop(Component c){
BundleContext bc =
c.getDependencyManager().getBundleContext();
bc.removeFrameworkListener((FrameworkListener) c.getService());
}
}, "notUsed", "start", "stop", "notUsed"));
Thanks & regards Philipp
PS: I understand that writing a whiteboard handler is not the issue -
the issue is probably that in the JavaDoc of FrameworkListener it says
"The Framework deliversFrameworkEvent objects to a FrameworkListener in
order (...)". Although its not specified in "what" order (order of
registration?), using a whiteboard approach cannot guarantee this
(AFAIU). Maybe some client code depends on the call order being the
registration order...
On 09.10.2014 12:17, Marcel Offermans wrote:
> Let me reverse the question: what would be a newer/better way and how should that be implemented. I mean I can see somebody writing a whiteboard style handler and donating it to (for example) Felix. Is that what you would like, or??
>
> On 09 Oct 2014, at 9:02 am, Bulu <bu...@romandie.com> wrote:
>
>> Hello Marcel
>> Yes I already knew the standard way you describe. I just wanted to clarify whether a newer/better method existed.
>>
>> Thanks again for your answer.
>> Philipp
>>
>> On 08.10.2014 11:24, Marcel Offermans wrote:
>>> From the spec: "A FrameworkListener object is registered with the Framework using the BundleContext.addFrameworkListener method.”
>>>
>>> So it is not whiteboard-style (it pre-dates the whiteboard pattern afaik).
>>>
>>> In DM I would do:
>>>
>>> in the init:
>>> dm.add(createComponent().setImplementation(Comp.class));
>>>
>>> and then the component:
>>> public class Comp implements FrameworkListener {
>>> private volatile BundleContext m_context;
>>> public void start() {
>>> m_context.addFrameworkListener(this);
>>> }
>>> public void stop() {
>>> m_context.removeFrameworkListener(this);
>>> }
>>> // implement the FrameworkListener methods here
>>> }
>>>
>>> of course it would also be possible to create a whiteboard style handler for this (just like one exists to handle Servlets for HttpService)…
>>>
>>> Greetings, Marcel
>>>
>>> On 8 Oct 2014 at 10:06:01 , Bulu (bulu@romandie.com) wrote:
>>>
>>> Hello all
>>>
>>> I'm declaring a component using DM which gets created when all
>>> dependencies are met. This component should also get notified of
>>> framework events and thus implements FrameworkListener.
>>>
>>> Does the OSGi framework also use a whiteboard pattern for delivering
>>> these events, meaning I only need to publish my component as a
>>> FrameworkListener.class service and it will get called by the framework
>>> when needed?
>>>
>>> If not, is there an elegant way of registering it using DM?
>>>
>>> Thanks & regards
>>> Philipp
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
Re: Dependency Manager: registering FrameworkListener
Posted by Marcel Offermans <ma...@luminis.eu>.
Let me reverse the question: what would be a newer/better way and how should that be implemented. I mean I can see somebody writing a whiteboard style handler and donating it to (for example) Felix. Is that what you would like, or??
On 09 Oct 2014, at 9:02 am, Bulu <bu...@romandie.com> wrote:
> Hello Marcel
> Yes I already knew the standard way you describe. I just wanted to clarify whether a newer/better method existed.
>
> Thanks again for your answer.
> Philipp
>
> On 08.10.2014 11:24, Marcel Offermans wrote:
>> From the spec: "A FrameworkListener object is registered with the Framework using the BundleContext.addFrameworkListener method.”
>>
>> So it is not whiteboard-style (it pre-dates the whiteboard pattern afaik).
>>
>> In DM I would do:
>>
>> in the init:
>> dm.add(createComponent().setImplementation(Comp.class));
>>
>> and then the component:
>> public class Comp implements FrameworkListener {
>> private volatile BundleContext m_context;
>> public void start() {
>> m_context.addFrameworkListener(this);
>> }
>> public void stop() {
>> m_context.removeFrameworkListener(this);
>> }
>> // implement the FrameworkListener methods here
>> }
>>
>> of course it would also be possible to create a whiteboard style handler for this (just like one exists to handle Servlets for HttpService)…
>>
>> Greetings, Marcel
>>
>> On 8 Oct 2014 at 10:06:01 , Bulu (bulu@romandie.com) wrote:
>>
>> Hello all
>>
>> I'm declaring a component using DM which gets created when all
>> dependencies are met. This component should also get notified of
>> framework events and thus implements FrameworkListener.
>>
>> Does the OSGi framework also use a whiteboard pattern for delivering
>> these events, meaning I only need to publish my component as a
>> FrameworkListener.class service and it will get called by the framework
>> when needed?
>>
>> If not, is there an elegant way of registering it using DM?
>>
>> Thanks & regards
>> Philipp
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Dependency Manager: registering FrameworkListener
Posted by Bulu <bu...@romandie.com>.
Hello Marcel
Yes I already knew the standard way you describe. I just wanted to
clarify whether a newer/better method existed.
Thanks again for your answer.
Philipp
On 08.10.2014 11:24, Marcel Offermans wrote:
> From the spec: "A FrameworkListener object is registered with the Framework using the BundleContext.addFrameworkListener method.”
>
> So it is not whiteboard-style (it pre-dates the whiteboard pattern afaik).
>
> In DM I would do:
>
> in the init:
> dm.add(createComponent().setImplementation(Comp.class));
>
> and then the component:
> public class Comp implements FrameworkListener {
> private volatile BundleContext m_context;
> public void start() {
> m_context.addFrameworkListener(this);
> }
> public void stop() {
> m_context.removeFrameworkListener(this);
> }
> // implement the FrameworkListener methods here
> }
>
> of course it would also be possible to create a whiteboard style handler for this (just like one exists to handle Servlets for HttpService)…
>
> Greetings, Marcel
>
> On 8 Oct 2014 at 10:06:01 , Bulu (bulu@romandie.com) wrote:
>
> Hello all
>
> I'm declaring a component using DM which gets created when all
> dependencies are met. This component should also get notified of
> framework events and thus implements FrameworkListener.
>
> Does the OSGi framework also use a whiteboard pattern for delivering
> these events, meaning I only need to publish my component as a
> FrameworkListener.class service and it will get called by the framework
> when needed?
>
> If not, is there an elegant way of registering it using DM?
>
> Thanks & regards
> Philipp
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: Dependency Manager: registering FrameworkListener
Posted by Marcel Offermans <ma...@luminis.nl>.
From the spec: "A FrameworkListener object is registered with the Framework using the BundleContext.addFrameworkListener method.”
So it is not whiteboard-style (it pre-dates the whiteboard pattern afaik).
In DM I would do:
in the init:
dm.add(createComponent().setImplementation(Comp.class));
and then the component:
public class Comp implements FrameworkListener {
private volatile BundleContext m_context;
public void start() {
m_context.addFrameworkListener(this);
}
public void stop() {
m_context.removeFrameworkListener(this);
}
// implement the FrameworkListener methods here
}
of course it would also be possible to create a whiteboard style handler for this (just like one exists to handle Servlets for HttpService)…
Greetings, Marcel
On 8 Oct 2014 at 10:06:01 , Bulu (bulu@romandie.com) wrote:
Hello all
I'm declaring a component using DM which gets created when all
dependencies are met. This component should also get notified of
framework events and thus implements FrameworkListener.
Does the OSGi framework also use a whiteboard pattern for delivering
these events, meaning I only need to publish my component as a
FrameworkListener.class service and it will get called by the framework
when needed?
If not, is there an elegant way of registering it using DM?
Thanks & regards
Philipp
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Dependency Manager: registering FrameworkListener
Posted by Bulu <bu...@romandie.com>.
Hello all
I'm declaring a component using DM which gets created when all
dependencies are met. This component should also get notified of
framework events and thus implements FrameworkListener.
Does the OSGi framework also use a whiteboard pattern for delivering
these events, meaning I only need to publish my component as a
FrameworkListener.class service and it will get called by the framework
when needed?
If not, is there an elegant way of registering it using DM?
Thanks & regards
Philipp
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: OSGI Security in Felix
Posted by "Richard S. Hall" <he...@ungoverned.org>.
On 10/6/14 06:13 , Andrew Scully wrote:
> Hello,
>
> I'm looking into domain security in OSGI. I've assembled a fairly complete
> picture of what this would involve, but I have a question which I would
> appreciate your thoughts on. It would also be useful to me to check that I
> have correctly understood so far.
>
> To reiterate what I think I know (please correct if wrong!):
> -I understand that setting permissions for the OSGI framework is something
> that must be done programatically using the ConditionalPermissionAdmin
> service. This is installed into Felix by an extension bundle.
> -A file format is specified for defining permissions declaratively, but no
> facility exists to automatically read a file in this format and bootstrap
> the policy into the framework during startup (as you can with standard Java
> security policies using a -D argument).
> -You can implement your own service for reading in such a file and passing
> the instructions to the ConditionalPermissionAdmin. Example code for this is
> given in the "OSGI in Action" book, which I have seen.
>
> Now here's my question!
>
> As noted in both in OSGI in Action and in this post --
> http://apache-felix.18485.x6.nabble.com/Felix-security-td4837010.html -- the
> first bundle to "get" the ConditionalPermissionAdmin service effectively
> controls the security for the entire framework, as it can change the
> permissions to prevent others from changing permissions.
>
> Obviously this is undesirable. The developer trying to secure the runtime
> environment will want to ensure that the correct policy is applied without
> the possibility of interference.
>
> Furthermore, timing seems important. Surely, if a developer is trying to
> prevent certain bundles from being installed, it would be no good if Felix
> had already installed those bundles before the "security policy reader"
> service had completed?
>
> Therefore my question is this: Is it possible for a developer to guarantee
> that their security policy is applied and is being enforced before the
> framework starts "proper"?
>
> To put that another way: If I implemented a bundle that read in an OSGI
> security policy file and applied these settings to the framework (and then
> locked it down preventing any further changes), how would I make sure that
> this bundle ran "first"? Ideally, initialization of the rest of the
> framework would be postponed until after this bundle had finished its work.
Assuming you are in control of the framework configuration and it is not
compromised, you just need to configure your framework to launch your
security bundle in start level 1 and put all other bundles in start
level 2 or above.
Another option is to not actually create a security bundle per se, but
to simply do it in your launcher. When you create a framework, you get
back the system bundle which you can then use its bundle context to get
the conditional permission service while still in the init phase and
then set up your permission policy before it even attempts to start any
other bundles.
-> richard
> Any help hugely appreciated -- it feels like I'm just missing some small
> step here!
>
> Cheers, Andy.
>
>
>
>
> --
> View this message in context: http://apache-felix.18485.x6.nabble.com/OSGI-Security-in-Felix-tp5010083.html
> Sent from the Apache Felix - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org