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 11:54:44 GMT
+1 for starting a Karaf-Extras on GitHub, as a osgi-geek-store ;)
for new fancy stuff to put on top of Karaf.

Achim

2012/1/16 Andreas Pieber <anpieber@gmail.com>

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



-- 

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