karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Freeman Fang <freeman.f...@gmail.com>
Subject Re: Some thoughts around adding security for Karaf Shell Commands
Date Fri, 16 Aug 2013 00:34:34 GMT
+1 for this proposal.

I like the idea that we needn't change current commands code, but hack it through service
registry hooks.
-------------
Freeman(Yue) Fang

Red Hat, Inc. 
FuseSource is now part of Red Hat
Web: http://fusesource.com | http://www.redhat.com/
Twitter: freemanfang
Blog: http://freemanfang.blogspot.com
http://blog.sina.com.cn/u/1473905042
weibo: @Freeman小屋



On 2013-8-15, at 下午10:26, davidb@apache.org wrote:

> Hi all,
> 
> In the context of KARAF-2442 I started looking at securing the commands in
> the shell. I wanted to do something similar to what I did for the JMX
> access (KARAF-2435) in that this should be configurable by a Karaf
> administrator. I also really wanted a generic solution that would work with
> all commands, so that there would not be a big burden on the command
> developer. I know that there was discussion about this in the context of
> Karaf before, my approach here is a bit different...
> 
> Here's what I came up with…
> Karaf Commands are implemented OSGi services and one of the lesser known
> features of the OSGi service registry is the fact that you can control
> service registrations through service registry hooks. This effectively
> allows you to change registrations, control who sees what registrations and
> also proxy service objects with some interceptor [1].
> I thought that this might be a nice tool to use to add security to the
> Karaf Commands from the outside, so I started an experimental
> implementation with this:
> * The roles that a specific Karaf Command needs in order to be executable
> are defined in a ConfigAdmin config file in the etc/ directory. So this can
> easily be modified by an administrator. E.g I have a file that controls who
> can use the feature command, some example content:
>  list = manager, viewer
>  install = manager
>  uninstall = admin
> * I added a mechanism that effectively changes command service
> registrations to add the required roles for the specific command - based on
> the ConfigAdmin data specified, e.g. the Service Registration for a
> features:list command is turned into the following:
>  osgi.command.scope=feature
>  osgi.command.function=list
>  org.apache.karaf.command.roles=[manager,viewer]
> * The CommandProcessorImpl class in Karaf keeps track of what commands are
> there. Previously this was a global instance, but now we need one instance
> per shell console that selects the right commands for the user of that
> console. It does this by reading off the current RolePrincipal objects
> (that were put there by the JAAS login) and only selecting those commands
> that have these roles by simply adding these as additional conditions to
> the OSGi Service Registry selection filter.
> * From there on everything works as normal. Tab completion etc, 'just
> works'.
> 
> The commands themselves are not modified. The required roles are added
> externally, which is really easy for the command developer.
> It's also pretty easy to change the required roles for commands either
> directly in the etc/...cfg files or via the ConfigAdmin API...
> 
> There are still a few things that I need to look at in more detail
> (including defaults), but I wanted to run this by everyone to see what
> people think, so feedback is appreciated!
> If you're interested, I implemented this on a branch here:
> https://github.com/bosschaert/karaf/commit/3e16bb515350bfb58e1a4b5d98045ccc1bcb1630
> 
> David
> 
> davidb@apache.org
> david@redhat.com
> david.bosschaert@gmail.com
> 
> [1] Detail: you don't really change a service registration, but can hide it
> from bundles and replace it with an alternative, which gives this effect… I
> wrote a blog about this a while ago:
> http://coderthoughts.blogspot.ie/2009/11/altering-osgi-service-lookups-with.html


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