karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ioannis Canellos <ioca...@gmail.com>
Subject Re: Database commands for Karaf
Date Mon, 16 Jan 2012 12:18:45 GMT
What do you think about having those stuff as part of KarafEE which is currently hosted as
an OpenEJB subproject?
It seems that its the ideal place to host those, it will reduce the maintenance overhead of
having an other subproject.


On 16 Ιαν 2012, at 1:54 μ.μ., Achim Nierbeck wrote:

> +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
View raw message