karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Database commands for Karaf
Date Mon, 16 Jan 2012 12:23:38 GMT
As these commands concern the "Enterprise Section" (datasource, 
database, connection factory, etc), we can:
- as I said in my first e-mail, store it in Aries (as Aries provides 
connection pool support, JPA, and the others enterprise feature)
- in KarafEE, depending of the OpenEJB guys

Regards
JB

On 01/16/2012 01:18 PM, Ioannis Canellos wrote:
> 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/>
>

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message