karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Some thoughts around adding security for Karaf Shell Commands
Date Fri, 23 Aug 2013 11:44:17 GMT
Good point David.


On 08/23/2013 01:00 PM, David Bosschaert wrote:
> That may be true for the Karaf MBeans but there are also other MBeans in
> the system. For example ones provided by the JVM. As an example take the
> MBean with the following object name: connector:name=rmi
> It is registered by the JVM and not through OSGi services and has a few
> operations (start(), stop()). By purely having the ACLs go through the
> service registry model you would not be able to prevent anyone from calling
> stop() on that mbean...
> It's just an example. Another example would be when an OSGi bundle
> registers MBeans directly (not through the WhiteBoard pattern). With the
> approach I suggest in KARAF-2435 you can secure any JMX operation,
> regardless of whether it's implemented as an OSGi service or not...
> Cheers,
> David
> On 23 August 2013 11:43, Jean-Baptiste Onofré <jb@nanthrax.net> wrote:
>> Hi guys,
>> @David, on trunk (3.0.0-SNAPSHOT), Karaf uses Aries JMX for MBean
>> registration. Aries JMX looks up for MBeans exposed as OSGi services. So I
>> think we can leverage it.
>> WDYT ?
>> Regards
>> JB
>> On 08/23/2013 10:41 AM, David Bosschaert wrote:
>>> Hi Christian,
>>> On 22 August 2013 23:14, Christian Schneider <chris@die-schneider.net>**
>>> wrote:
>>>   Sounds great. I have not yet looked into it in detail but the concept
>>>> sounds decent.
>>>> One thing you should keep in mind is to make the authorization
>>>> exchangeable. For example at Talend we provide an xacml based pdp. So it
>>>> would be great to have a hook wehere we can plug this in to
>>>> do the auth decisions. Personally I am not a fan of xacml but this shows
>>>> that different organizations would probably like to treat this
>>>> differently.
>>> What I did provides the authorization roles completely through
>>> ConfigAdmin.
>>> Which is pluggable in a number of ways: in Karaf we use the Felix Config
>>> admin which allows the registration of additional configuration providers.
>>> You can also replace the Config Admin Service itself to provide the info
>>> from another place...
>>> I guess we can always add more pluggability if that's needed.
>>>   The way round your aproach sounds much more maintainable than xacml. So
>>>> it
>>>> might even be interesting to attach a pdp to your authorization impl :-)
>>> :)
>>>   I have one other idea. How about doing the authorization for jmx and
>>>> commands only on the service level? At least in karaf 3 both use the same
>>>> services so securing only the service instead of jmx and commands would
>>>> reduce the number of config settings needed.
>>>> For example:
>>>> jmx: featureJMXBean.install(****feature)
>>>> command: feature:install <feature>
>>>> Both would be secured by simply securing the FeatureService.
>>> The problem with this is that there are still JMX APIs that aren't
>>> provided
>>> as OSGi services so that would leave a pretty big hole in the security if
>>> you ask me...
>>> For those cases where a single Service covers both JMX and the console we
>>> could use a single security point (that would be just a matter of
>>> configuring it that way), but I think that we still need the direct JMX
>>> security to make sure people can't do any damage through any of the
>>> non-OSGi-Service MBeans...
>>>   One thing I am not sure about btw. is doing too much magic behind the
>>>> scenes. Like the config admin config you described that causes other
>>>> configs to be created on the fly. Perhaps we find a simpler model that
>>>> also
>>>> works. Currently I do not have a good idea how to handle it though.
>>> I agree. We need to find the balance between simplicity and ease-of-use.
>>> If
>>> you think of a simpler way without configuration generation that doesn't
>>> make the thing horrilbly hard to use for commands I'd love to hear it.
>>> Cheers,
>>> David
>> --
>> Jean-Baptiste Onofré
>> jbonofre@apache.org
>> http://blog.nanthrax.net
>> Talend - http://www.talend.com

Jean-Baptiste Onofré
Talend - http://www.talend.com

View raw message