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 13:27:19 GMT
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

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

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