karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: Database commands for Karaf
Date Mon, 16 Jan 2012 09:41:29 GMT
You are certainly right, that the new db-command doesn't impose more
security threads, than
what we have already on board. It just makes it much more simpler :)
But to get back to the original Question raised here I still don't think
the core of Karaf is the main scope for
additional nice features, we could add a sub-project containing lot's of
different Additional shell-commands, MBeans and what so ever
as a App-Store kind-a-thing :)

Regards, Achim

2012/1/16 Guillaume Nodet <gnodet@gmail.com>

> The real problem about securing the shell is that the shell allow the
> use of introspection.  So even if we put authorization at the command
> level, anybody can easily access the osgi bundle context and really do
> mostly everything from there.
> So in order to secure the shell, we'd have to disable scripting as a
> whole and only enable a limited set of commands.
>
> Anyway, until we can secure the shell, I don't really think having a
> security leak in the DB is a big problem really.  Any user with access
> can already use the connection if available as an OSGi service and
> send sql statements from there.  I'm quite sure it's already doable
> via scripting, just a bit verbose.
>
> On Sun, Jan 15, 2012 at 16:23, Claus Ibsen <claus.ibsen@gmail.com> wrote:
> > On Sun, Jan 15, 2012 at 2:56 PM, Christian Schneider
> > <chris@die-schneider.net> wrote:
> >> I see no real security problem in the commands themselves. The
> DataSource is
> >> a security risk though. Typically datasources are defined with full
> >> credentials of a technical user that may access the database. So whoever
> >> logs into karaf has access to the db with that technical user.
> Typically on
> >> a production system only the sys admins have access to the karaf server
> so
> >> this is no big issue. Having the credentials with the DataSource even
> is a
> >> good thing for security as this way the developers do not need to know
> this
> >> technical user and password.
> >>
> >
> > This is still a security risk, and in some industries this is a NO GO.
> >
> > Even power sys admins, should NOT be able to query against any
> > database just because they can SSH into an application server.
> > The security model in Karaf is currently weak, where everybody is
> > basically *admins*. And there is no audit logs, and whatnot.
> > (As I understand Karaf 2.x)
> >
> >
> >> The reason why I say that the commands do not pose any additional risk
> is
> >> that a user with access to karaf can install bundles so he could easily
> >> install his own bundle that uses the datasource. So the commands only
> make
> >> it easier but do not really make a difference.
> >>
> >
> > Well that is because the security model in Karaf is too coarse
> > grained, eg everybody is *admin*.
> > (As I understand Karaf 2.x)
> >
> >
> >> As a consequence I think it would make sense to at least optionally
> secure
> >> the DataSource OSGi service. I am not sure how this works but OSGi
> probably
> >> provides a mechanism to secure services so we could leverage this.
> >>
> >> We also could tie the commands to a security group to limit who can do
> which
> >> things. That is a bigger thing though and basically applies to alle
> karaf
> >> commands.
> >>
> >
> > Yes, I think Karaf have reached a level of maturity and attention for
> > other projects to consider using Karaf
> > as their application container. And to make this more appealing and
> > also for Karaf to be more accepted
> > in enterprises, then IMHO a more fine grained security model should be
> > in place.
> >
> > For example the shell is too powerful out of the box.
> > Just doing osgi:shutdown, or osgi:uninstall or whatever, everybody can
> do.
> > And as I understand it would then not even be easy to track down who
> > did the command, as its not audit logged.
> > (As I understand Karaf 2.x)
> >
> > Would be nice to consider a more fine grained security model, and even
> > have individual commands being
> > able to tie into a group. However there is already a lot of commands,
> > but being able to have a more sensible
> > level of groups would be nice.
> >
> > And I guess there is already hooks to provide in an audit
> > functionality so every commands can be audit logged.
> > And people can plugin their custom adapter for this. Like they can for
> > security with JAAS.
> >
> >
> > Sorry for ranting if you guys feel like that. But it's just that Karaf
> > is so sexy now, that IMHO security, hooks for audit logs,
> > and being able to customize access in Karaf is an enterprise feature
> > IMHO it must start to look into providing.
> >
> > For example why should any end user be able to see the system level
> > bundles and whatnot. How can you restrict
> > so he can only list all/his applications. And for multi tenancy
> > applications type, how do you restrict between different "groups"?
> >
> >
> >
> >> Christian
> >>
> >>
> >> Am 15.01.2012 13:43, schrieb David Jencks:
> >>
> >>> I don't quite understand the security problem, but maybe I'm thinking
> of a
> >>> different environment.  I would expect an environment where the db
> enforces
> >>> user level access to that user's data to be set up in the app server
> using
> >>> container based security, where the app server maps the user identity
> and
> >>> credentials that it uses to the identity and credentials for the db
> (for
> >>> instance, they might be the same) and supplies the db-level user info
> to the
> >>> connection as it is obtained from the pool.  So if you log into karaf
> using
> >>> ssh, your identity will then be supplied to the db and you can only
> see and
> >>> manipulate your own data.  I don't know what connection management
> framework
> >>> this proposal was thinking of but geronimo connection management
> supports
> >>> this.
> >>>
> >>> If you were thinking that the application would enforce the user level
> >>> security, not the database, and all db connections would use the same
> db
> >>> user identity, then there is more of a problem, but I would expect
> that if a
> >>> malicious user could ssh into a server there are bigger problems than
> this.
> >>>
> >>> BTW perhaps geronimo would be a better place than aries for this, if it
> >>> doesn't end up in karaf.  It's not a new enterprise technology, it's
> more of
> >>> a usability extension to existing enterprise functionality.
> >>>
> >>> thanks
> >>> david jencks
> >>>
> >>> On Jan 15, 2012, at 1:56 AM, Claus Ibsen wrote:
> >>>
> >>>> Hi
> >>>>
> >>>> At first thought the commands seems cool.
> >>>>
> >>>> However one part (the SQL execute) they risk introduce a security
> >>>> vulnerability, as a malicious user can use these commands to access
> >>>> production database, and manipulate the data. And by using the same
> >>>> datasource/connection that applications uses, so its harder for the
> >>>> RDBMS to control user access.
> >>>> In some industrires, users must *never* access a database using an
> >>>> application account, by must always use their personal account (such
> >>>> as health care)
> >>>> to ensure that they can always track who have accessed the data
> >>>> (auditing). So with this new command, a malicious user can SSH into
a
> >>>> remote box, and use the application database connection to access the
> >>>> production database. And thus "hide" as the RDMBS would think it was
> >>>> the application that did the SQL.
> >>>>
> >>>> I guess this could be remedied by having the SQL execute command to
> >>>> must have the username / password provided, and "somehow" create a new
> >>>> connection to the application database. So its 100% separated from the
> >>>> application usage.
> >>>>
> >>>> The other pieces of the command is nice. Being able to list the
> >>>> datasources and details about their connection pools would be great.
> >>>> Just as you have in JEE servers. People may expect something similar
> >>>> in the world of Karaf.
> >>>>
> >>>> Maybe a "Karaf Shell Extensions" or "Karaf App Store" :) is in place.
> >>>> There could be a ton of small and custom shells being created.
> >>>> That people can install and use in their Karaf. I guess some targeted
> >>>> for developers, and others may for production usage.
> >>>> And having a SQL executor shell could be nice for the developer.
> >>>>
> >>>>
> >>>>
> >>>> On Fri, Jan 13, 2012 at 5:13 PM, Christian Schneider
> >>>> <chris@die-schneider.net>  wrote:
> >>>>>
> >>>>> Hi all,
> >>>>>
> >>>>> as part of my Karaf Tutorial about database access I have writte
some
> >>>>> handy
> >>>>> Karaf shell commands for databases.
> >>>>> They are described with screen dumps in my Tutorial
> >>>>> http://www.liquid-reality.de/x/LYBk .
> >>>>>
> >>>>> Especially for embedded databases like derby and h2 I missed a simple
> >>>>> access
> >>>>> to the database for a long time. So I think these commands could
be
> >>>>> interesting for many developers.
> >>>>>
> >>>>> So I would like to add them to Karaf and also add a feature for
> them. Of
> >>>>> course DB commands are not the core domain of Karaf so this is surely
> >>>>> nothing for the Karaf minimal distro but I propose to add them to
the
> >>>>> standard distro.
> >>>>>
> >>>>> The reasons are simple:
> >>>>> - I think many people could have use for the commands
> >>>>> - They add no dependencies
> >>>>> - The code is really small (just 16kb)
> >>>>>
> >>>>> Christian
> >>>>>
> >>>>> --
> >>>>> Christian Schneider
> >>>>> http://www.liquid-reality.de
> >>>>>
> >>>>> Open Source Architect
> >>>>> Talend Application Integration Division http://www.talend.com
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Claus Ibsen
> >>>> -----------------
> >>>> FuseSource
> >>>> Email: cibsen@fusesource.com
> >>>> Web: http://fusesource.com
> >>>> Twitter: davsclaus, fusenews
> >>>> Blog: http://davsclaus.blogspot.com/
> >>>> Author of Camel in Action: http://www.manning.com/ibsen/
> >>
> >>
> >>
> >> --
> >>
> >> Christian Schneider
> >> http://www.liquid-reality.de
> >>
> >> Open Source Architect
> >> Talend Application Integration Division http://www.talend.com
> >>
> >
> >
> >
> > --
> > Claus Ibsen
> > -----------------
> > FuseSource
> > Email: cibsen@fusesource.com
> > Web: http://fusesource.com
> > Twitter: davsclaus, fusenews
> > Blog: http://davsclaus.blogspot.com/
> > Author of Camel in Action: http://www.manning.com/ibsen/
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> FuseSource, Integration everywhere
> http://fusesource.com
>



-- 

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>

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