Re: [Discussion] Security improvements

[Guillaume Nodet <gn...@gmail.com>]

Another use case which we should support somehow would be to replace
the confirmations we have on bundle:start etc... using real
permissions.
That may also be linked to regions, where some users may only have
rights to interact with the content of a subset of regions.

2012/1/30 Guillaume Nodet <gn...@gmail.com>:
> 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 <gn...@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 <lu...@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 <lu...@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. <ja...@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
>
>
>
> --
> ------------------------
> 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