karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Łukasz Dywicki <l...@code-house.org>
Subject Re: [Discussion] Security improvements
Date Mon, 30 Jan 2012 15:08:58 GMT
Guillaume,
My goal is to provide fine grained access control. Not only a read or write access but also
domain specific, just imagine that you have a production installation and developers have
read only access to Apache Camel metrics, JMS Queues and OSGi bundles but also have write
access to configuration.

These changes will let you to create real profiles. Currently we do not have hierarchical
roles which makes management of accounts harder. All changes I made in webconsole is to let
you create an hierarchy where dash is level separator.

With these changes we might have something like that:
+ root
    + osgi
        - list
        - install
    + karaf
        + admin
            - list / stop / start / create / destroy
        + feature
            - list / stop / start / install / uninstall
    + camel
        + context
            - list / start / stop etc. (whole path is camel-context-list)
        + route (same operations like for context)

With this separation you might assign a whole node (osgi) or only leaf (osgi-list). I think
that limiting access rights only to two - read and write for container is really too little.
We do not provide access profiles, but we might consider that. Although I am sure this can
be done separately after introduction of fine grained roles.

Best regards,
Łukasz Dywicki
--
Code-House
http://code-house.org


Wiadomość napisana przez Guillaume Nodet w dniu 2012-01-30, o godz. 14:30:

> As I explained, I'm not sure which use case you're trying to achieve,
> but that does not address the only use case I've heard about, which is
> to be able to have profiles that are read-only and profiles that have
> read-write access.
> 
> 2012/1/30 Łukasz Dywicki <luke@code-house.org>:
>> Hey guys,
>> I am about to complete some changes in webconsole.
>> 
>> Currently the schema is following.
>> To view list of bundles you need a osgi-list role.
>> To install bundle you need a osgi-install role assigned and so on.
>> 
>> To execute all osgi related operations, read or write, you need a "osgi" role. If
you wish assign all karaf related roles you need karaf role. To manage instances you need
karaf-admin role (karaf-admin-list to view instances, karaf-admin-stop to stop etc), or karaf-feature
(and similar karaf-feature-list, stop, start). Does it seems reasonable? Maybe we can align
these roles with 3.0 command naming schema?
>> 
>> Best regards,
>> Łukasz Dywicki
>> --
>> Code-House
>> http://code-house.org
>> 
>> 
>> Wiadomość napisana przez Andreas Pieber w dniu 2012-01-22, o godz. 11:28:
>> 
>>> +1 that we try to include this/tackle this in 3.1
>>> 
>>> Kind regards,
>>> Andreas
>>> 
>>> 2012/1/20 Jamie G. <jamie.goodyear@gmail.com>
>>> 
>>>> +1 to tackling this major feature in 3.1.x.
>>>> 
>>>> Cheers,
>>>> Jamie
>>>> 
>>>> 2012/1/20 Jean-Baptiste Onofré <jb@nanthrax.net>:
>>>>> Hi Lukasz,
>>>>> 
>>>>> Agree to include it in Karaf 3.1.0. We live like this since a "long"
>>>> time,
>>>>> so no hurry. However, I consider it's a major enhancement that we have
to
>>>>> address in Karaf 3.1.x as it's a must have for a fully enterprise
>>>> compliant
>>>>> container.
>>>>> 
>>>>> I raised a Jira about that (as you mentionned, it's KARAF-1148).
>>>>> 
>>>>> Regards
>>>>> JB
>>>>> 
>>>>> 
>>>>> On 01/19/2012 11:16 PM, Łukasz Dywicki wrote:
>>>>>> 
>>>>>> Hey all,
>>>>>> One topic we started discussing last time is a better control of
>>>> commands.
>>>>>> Currently any user who can log in the Karaf remote shell is able
to
>>>> execute
>>>>>> all the commands. That obviously do not fit any security standards.
To
>>>>>> introduce improvements we need take some steps who affects current
Karaf
>>>>>> codebase. Because need of 3.0 release I think we can introduce  these
>>>>>> changes in version 3.1. Putting this stuff into 3.0 will only delay
>>>>>> everything. That will be also good ocasion to align security in shell,
>>>>>> mbeans and webconsole.
>>>>>> 
>>>>>> Problems we have currently are following:
>>>>>> - We support only an admin role. Once you have admin role you can
access
>>>>>> everything. Without it you cannot access anything.
>>>>>> - JMX security layer specify only two types of access - Read or Read
>>>>>> Write.
>>>>>> - Some MBeans comes from external projects - eg. Camel or Aries,
we can
>>>>>> not force these projects to introduce Karaf dependencies into libraries
>>>>>> core.
>>>>>> - Current shell security is really simple, it do not verify command
>>>>>> execution context, eg what resources are involved.
>>>>>> - We do not have any role OR permission naming schema.
>>>>>> - In some areas the security stuff can be in conflict with JAAS modules,
>>>>>> by default policy files can control socket access without need to
assign
>>>>>> roles.
>>>>>> 
>>>>>> That's only few concerns I have. Currently the issue KARAF-1148 reflects
>>>>>> some points from this mail, but it's far from a solution proposal.
>>>>>> 
>>>>>> Best regards,
>>>>>> Łukasz Dywicki
>>>>>> --
>>>>>> Code-House
>>>>>> http://code-house.org
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>>> --
>>>>> Jean-Baptiste Onofré
>>>>> jbonofre@apache.org
>>>>> http://blog.nanthrax.net
>>>>> Talend - http://www.talend.com
>>>> 
>> 
> 
> 
> 
> -- 
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com


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