Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
Received-SPF: pass (athena.apache.org: domain of anpieber@gmail.com designates
 209.85.215.48 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAD0r13cqh+1HnNEYdJBt9gGxQC8esDknV8SHB7NpupXL70K6Vw@mail.gmail.com>
References: <4F10581C.7090803@die-schneider.net>
	<CAGB5yNnD1iU7wyxeurVLZqtUXG6htWMtw+Lw7Psm7wzCPGG0Uw@mail.gmail.com>
	<0174D97A-D912-4EC7-A4C0-9083E44EFF91@yahoo.com>
	<4F12DB0D.2020705@die-schneider.net>
	<CAGB5yNnjG16y5Z7L4WUR3qqi1cpPUJ3Zz_s+jZTpaXKyejkf3Q@mail.gmail.com>
	<CAEQV+EHQAKeSFS31eH3Mw0waFHNd022b_xTCKPf8VTN853i8aw@mail.gmail.com>
	<CAD0r13cqh+1HnNEYdJBt9gGxQC8esDknV8SHB7NpupXL70K6Vw@mail.gmail.com>
Date: Mon, 16 Jan 2012 11:53:54 +0100
Message-ID: 
 <CAK--DP9JPBYfzskAWomF44ofqzcjzyuKG8MvJCohjaDMy1D6SA@mail.gmail.com>
Subject: Re: Database commands for Karaf
From: Andreas Pieber <anpieber@gmail.com>
To: dev@karaf.apache.org
Content-Type: multipart/alternative; boundary=bcaec554d962d6976c04b6a30741

--bcaec554d962d6976c04b6a30741
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Jan 16, 2012 at 10:41, Achim Nierbeck <bcanhome@googlemail.com>wrote:

> 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 :)
>

Yeah, I've thought that too, but it would definitely be of advantage to
have own release cycles per module; Therefore I'm curious if it isn't
easier to create a karaf-extras at e.g. github or google code
(apache-extras). BTW, we shouldn't call the thing App-store; otherwise
Apple will sue us ;-) I think choosing gadget store as a name would be
saver (and cheaper :-))...

Kind regards,
Andreas


>
> 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/>
>

--bcaec554d962d6976c04b6a30741--