karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Guillaume Nodet <gno...@gmail.com>
Subject Re: [Discussion] Security improvements
Date Mon, 30 Jan 2012 15:28:19 GMT
Then, we're talking more about authorization than roles, which makes
sense to me.
But we should not mix both.  So what you're wiring is more command
level authorization, but we should not use roles to explicit those.

Defining a role per command is just not scalable and new commands
won't be able to leverage them.  I think we need a mechanism that can
support coarse grained role definition and I don't think this goes in
that way.

I may have missed something in your explanation, but I don't really
like the idea to have one role per command.

2012/1/30 Łukasz Dywicki <luke@code-house.org>:
> 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
>



-- 
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com

Mime
View raw message