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.

Regards
JB

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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message