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 13:30:59 GMT
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
View raw message