karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jamie G." <jamie.goody...@gmail.com>
Subject Re: [Discussion] Security improvements
Date Fri, 20 Jan 2012 17:05:33 GMT
+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

Mime
View raw message