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:59:45 GMT
One big use case I've seen is when you have a production environment
and you want to allow people to connect to *see* things, but obviously
not everybody to make changes.  And such roles should not have to be
modified when you install new bundles.  Which means commands have to
be assigned into one or more predefined roles, rather than having to
change the roles whenever you deploy a new set of commands.

Also, as I already warned, unless we agree to consider those security
bits as not secured, but rather cosmetic, the first thing to do is to
have a way to disable reflection in the gogo shell.

On top of this very simple read or read-write mechanism, we could then
have finer grained authorization, but authorization is really not the
same as authentication / roles.
And I'm not sure using jaas for such a fine grain authorization
mechanism is a good idea.

Fwiw, I think you're right representing the commands in a tree, but
then we should have a layer to map part of this tree to known roles.
But I think having a read and read/write orthogonal concept is needed.

I think we can combine both.  If each command is annotated with a
@Read or @Write and have those mapped to a role and then having a
layer mapping command names / scopes and have part of this tree mapped
to required roles too.

That would allow an easy mapping of (for example)
  * all write operations require an admin role
  * all config operations require a deployer role

2012/1/30 Guillaume Nodet <gnodet@gmail.com>:
> 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
>>>>>> 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
>>>>>> 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
>>>>>>>> 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
>>>>>>>> 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
>>>>>>>> some points from this mail, but it's far from a solution
>>>>>>>> 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

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

View raw message