karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Pieber <anpie...@gmail.com>
Subject Re: [Discussion] Security improvements
Date Sun, 22 Jan 2012 10:28:26 GMT
+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
>

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