You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by Christian Schneider <ch...@die-schneider.net> on 2012/01/13 17:13:16 UTC
Database commands for Karaf
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
Re: Database commands for Karaf
Posted by Andreas Pieber <an...@gmail.com>.
2012/1/17 Jean-Baptiste Onofré <jb...@nanthrax.net>
> Hi guys,
>
> let me try to summarise the different options:
> - include in Karaf: it's not a good idea as the commands scope is not
> purely container related
> - include in a Karaf sub-project (as Karaf Extra on google, or a pure
> sub-project as Cellar, WebConsole, Cave and EIK). Pros: we control/are the
> community, the release cycle, etc. Cons: it's more difficult for others
> communities to join and contribute.
> - include in a KarafEE. It means in OpenEJB. It makes sense but we are not
> involved in the OpenEJB community. More over, KarafEE is new and a "lot" of
> stuff should be done
> - include in Geronimo. Geronimo already use Karaf and some of us are
> involved in the Geronimo communities. It could be interesting but it means
> that we should be more involved in the Geronimo community.
> - include in ServiceMix. We are most of all involved in the ServiceMix
> community. It could be a good location even if it's not the core purpose of
> ServiceMix.
>
I really like the idea with SMX. Wil give a little bit more fire to the
project, involve more communities (and will finally provide a reason for me
to contribute to the project :-)). The only question is: do they wont those
projects there? In addition we should not couple the releases of those
"minor commands" to smx itself since it would be simply too slow for such
small standalone features/commands.
Kind regards,
Andreas
>
> Regards
> JB
>
>
> On 01/16/2012 11:21 PM, Łukasz Dywicki wrote:
>
>> Hey all,
>> I would opt for some from Apache repositories too, since we all have
>> access to them. I preffer a ServiceMix as destination project because from
>> following reasons:
>>
>> 1) We have more Karaf commiters in ServiceMix than in any other project
>> listed before
>> 2) Our communities in past was strictly connected and we still cooperate
>> very well
>> 3) It looks like an application server domain but it don't have to be -
>> exposed connection factory can point to external IBM MQ or Oracle broker
>> 4) ServiceMix can still be used with Geronimo, and these commands, if
>> we'll keep dependencies clear, can be part of Geronimo distribution to
>>
>> Only one problem we have is a big question mark regarding SMX5 project
>> scope discussed few months before. If it still be a OSGi ready or not. But
>> so far development on 5th release is almost nothing and we can focus on
>> SMX4 and OSGi doing some improvements for community eg in ServiceMix 4.4.
>> That can proof that OSGi is the best choice for runtime. :)
>>
>> Gute nacht
>> Łukasz Dywicki
>> --
>> Code-House
>> http://code-house.org
>>
>>
>> Wiadomość napisana przez Ioannis Canellos w dniu 2012-01-16, o godz.
>> 19:47:
>>
>> I think the most appropriate place for this kind of stuff is geronimo
>>>> since the general idea for geronimo is to provide EE funcionality that
>>>> elaborates other projects.
>>>>
>>>
>>> Yeah, Geronimo would be a great place too, as long as it can provide a
>>> feature descriptor that would allow its use in plain Karaf. But I really
>>> don't think that this would be a problem.
>>>
>>> --
>>> *Ioannis Canellos*
>>> *
>>> FuseSource<http://fusesource.**com <http://fusesource.com>>
>>>
>>> **
>>> Blog: http://iocanel.blogspot.com
>>> **
>>> Apache Karaf<http://karaf.apache.org/**> Committer& PMC
>>>
>>> Apache Camel<http://camel.apache.org/**> Committer
>>> Apache ServiceMix<http://servicemix.**apache.org/<http://servicemix.apache.org/>>
>>> Committer
>>> Apache Gora<http://incubator.apache.**org/gora/<http://incubator.apache.org/gora/>>
>>> Committer
>>> Apache DirectMemory<http://incubator.**apache.org/directmemory/<http://incubator.apache.org/directmemory/>>
>>> Committer
>>> *
>>>
>>
>>
> --
> Jean-Baptiste Onofré
> jbonofre@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>
Re: Database commands for Karaf
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi guys,
let me try to summarise the different options:
- include in Karaf: it's not a good idea as the commands scope is not
purely container related
- include in a Karaf sub-project (as Karaf Extra on google, or a pure
sub-project as Cellar, WebConsole, Cave and EIK). Pros: we control/are
the community, the release cycle, etc. Cons: it's more difficult for
others communities to join and contribute.
- include in a KarafEE. It means in OpenEJB. It makes sense but we are
not involved in the OpenEJB community. More over, KarafEE is new and a
"lot" of stuff should be done
- include in Geronimo. Geronimo already use Karaf and some of us are
involved in the Geronimo communities. It could be interesting but it
means that we should be more involved in the Geronimo community.
- include in ServiceMix. We are most of all involved in the ServiceMix
community. It could be a good location even if it's not the core purpose
of ServiceMix.
Regards
JB
On 01/16/2012 11:21 PM, Łukasz Dywicki wrote:
> Hey all,
> I would opt for some from Apache repositories too, since we all have access to them. I preffer a ServiceMix as destination project because from following reasons:
>
> 1) We have more Karaf commiters in ServiceMix than in any other project listed before
> 2) Our communities in past was strictly connected and we still cooperate very well
> 3) It looks like an application server domain but it don't have to be - exposed connection factory can point to external IBM MQ or Oracle broker
> 4) ServiceMix can still be used with Geronimo, and these commands, if we'll keep dependencies clear, can be part of Geronimo distribution to
>
> Only one problem we have is a big question mark regarding SMX5 project scope discussed few months before. If it still be a OSGi ready or not. But so far development on 5th release is almost nothing and we can focus on SMX4 and OSGi doing some improvements for community eg in ServiceMix 4.4. That can proof that OSGi is the best choice for runtime. :)
>
> Gute nacht
> Łukasz Dywicki
> --
> Code-House
> http://code-house.org
>
>
> Wiadomość napisana przez Ioannis Canellos w dniu 2012-01-16, o godz. 19:47:
>
>>> I think the most appropriate place for this kind of stuff is geronimo
>>> since the general idea for geronimo is to provide EE funcionality that
>>> elaborates other projects.
>>
>> Yeah, Geronimo would be a great place too, as long as it can provide a
>> feature descriptor that would allow its use in plain Karaf. But I really
>> don't think that this would be a problem.
>>
>> --
>> *Ioannis Canellos*
>> *
>> FuseSource<http://fusesource.com>
>>
>> **
>> Blog: http://iocanel.blogspot.com
>> **
>> Apache Karaf<http://karaf.apache.org/> Committer& PMC
>> Apache Camel<http://camel.apache.org/> Committer
>> Apache ServiceMix<http://servicemix.apache.org/> Committer
>> Apache Gora<http://incubator.apache.org/gora/> Committer
>> Apache DirectMemory<http://incubator.apache.org/directmemory/> Committer
>> *
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Database commands for Karaf
Posted by Łukasz Dywicki <lu...@code-house.org>.
Hey all,
I would opt for some from Apache repositories too, since we all have access to them. I preffer a ServiceMix as destination project because from following reasons:
1) We have more Karaf commiters in ServiceMix than in any other project listed before
2) Our communities in past was strictly connected and we still cooperate very well
3) It looks like an application server domain but it don't have to be - exposed connection factory can point to external IBM MQ or Oracle broker
4) ServiceMix can still be used with Geronimo, and these commands, if we'll keep dependencies clear, can be part of Geronimo distribution to
Only one problem we have is a big question mark regarding SMX5 project scope discussed few months before. If it still be a OSGi ready or not. But so far development on 5th release is almost nothing and we can focus on SMX4 and OSGi doing some improvements for community eg in ServiceMix 4.4. That can proof that OSGi is the best choice for runtime. :)
Gute nacht
Łukasz Dywicki
--
Code-House
http://code-house.org
Wiadomość napisana przez Ioannis Canellos w dniu 2012-01-16, o godz. 19:47:
>> I think the most appropriate place for this kind of stuff is geronimo
>> since the general idea for geronimo is to provide EE funcionality that
>> elaborates other projects.
>
> Yeah, Geronimo would be a great place too, as long as it can provide a
> feature descriptor that would allow its use in plain Karaf. But I really
> don't think that this would be a problem.
>
> --
> *Ioannis Canellos*
> *
> FuseSource <http://fusesource.com>
>
> **
> Blog: http://iocanel.blogspot.com
> **
> Apache Karaf <http://karaf.apache.org/> Committer & PMC
> Apache Camel <http://camel.apache.org/> Committer
> Apache ServiceMix <http://servicemix.apache.org/> Committer
> Apache Gora <http://incubator.apache.org/gora/> Committer
> Apache DirectMemory <http://incubator.apache.org/directmemory/> Committer
> *
Re: Database commands for Karaf
Posted by Ioannis Canellos <io...@gmail.com>.
> I think the most appropriate place for this kind of stuff is geronimo
> since the general idea for geronimo is to provide EE funcionality that
> elaborates other projects.
Yeah, Geronimo would be a great place too, as long as it can provide a
feature descriptor that would allow its use in plain Karaf. But I really
don't think that this would be a problem.
--
*Ioannis Canellos*
*
FuseSource <http://fusesource.com>
**
Blog: http://iocanel.blogspot.com
**
Apache Karaf <http://karaf.apache.org/> Committer & PMC
Apache Camel <http://camel.apache.org/> Committer
Apache ServiceMix <http://servicemix.apache.org/> Committer
Apache Gora <http://incubator.apache.org/gora/> Committer
Apache DirectMemory <http://incubator.apache.org/directmemory/> Committer
*
Re: Database commands for Karaf
Posted by David Jencks <da...@yahoo.com>.
I think the most appropriate place for this kind of stuff is geronimo since the general idea for geronimo is to provide EE funcionality that elaborates other projects.
We have a "components" set of subprojects already. (we also have this kind of functionality in the geronimo admin console already, but it's not in an osgi friendly form yet).
I'm -1 on non-apache locations and I really don't think this fits with openejb any better than karaf.
thanks
david jencks
On Jan 16, 2012, at 4:29 AM, Christian Schneider wrote:
> I would be fine with both options.
>
> Christian
>
> Am 16.01.2012 13:23, schrieb Jean-Baptiste Onofré:
>> 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
>>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>
Re: Database commands for Karaf
Posted by Christian Schneider <ch...@die-schneider.net>.
I would be fine with both options.
Christian
Am 16.01.2012 13:23, schrieb Jean-Baptiste Onofré:
> 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
>
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
Re: Database commands for Karaf
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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<an...@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<gn...@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<cl...@gmail.com>
>>>> wrote:
>>>>>> On Sun, Jan 15, 2012 at 2:56 PM, Christian Schneider
>>>>>> <ch...@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
>>>>>>>>> <ch...@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
Re: Database commands for Karaf
Posted by Ioannis Canellos <io...@gmail.com>.
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 <an...@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 <gn...@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 <cl...@gmail.com>
>>> wrote:
>>>>> On Sun, Jan 15, 2012 at 2:56 PM, Christian Schneider
>>>>> <ch...@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
>>>>>>>> <ch...@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/>
Re: Database commands for Karaf
Posted by Achim Nierbeck <bc...@googlemail.com>.
+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 <an...@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 <gn...@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 <cl...@gmail.com>
> > wrote:
> > > > On Sun, Jan 15, 2012 at 2:56 PM, Christian Schneider
> > > > <ch...@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
> > > >>>> <ch...@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/>
Re: Database commands for Karaf
Posted by Andreas Pieber <an...@gmail.com>.
On Mon, Jan 16, 2012 at 10:41, Achim Nierbeck <bc...@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 <gn...@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 <cl...@gmail.com>
> wrote:
> > > On Sun, Jan 15, 2012 at 2:56 PM, Christian Schneider
> > > <ch...@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
> > >>>> <ch...@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/>
>
Re: Database commands for Karaf
Posted by Achim Nierbeck <bc...@googlemail.com>.
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 <gn...@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 <cl...@gmail.com> wrote:
> > On Sun, Jan 15, 2012 at 2:56 PM, Christian Schneider
> > <ch...@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
> >>>> <ch...@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/>
Re: Database commands for Karaf
Posted by Guillaume Nodet <gn...@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 <cl...@gmail.com> wrote:
> On Sun, Jan 15, 2012 at 2:56 PM, Christian Schneider
> <ch...@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
>>>> <ch...@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
Re: Database commands for Karaf
Posted by Claus Ibsen <cl...@gmail.com>.
On Sun, Jan 15, 2012 at 2:56 PM, Christian Schneider
<ch...@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
>>> <ch...@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/
Re: Database commands for Karaf
Posted by Christian Schneider <ch...@die-schneider.net>.
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.
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.
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.
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
>> <ch...@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
Re: Database commands for Karaf
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Achim,
FYI, last week I raised:
https://issues.apache.org/jira/browse/KARAF-1148
The purpose is to use the Karaf JAAS layer (and group especially), to
define security policy associated (for instance, this group can launch
this command or access to this MBean, but not this group).
Regards
JB
On 01/16/2012 10:11 AM, Achim Nierbeck wrote:
> Hi,
>
> I pretty much liked the idea of Claus, that a "app-store" kind-of-thing
> could be the home for such neat shell/other-stuff improvments on top of
> Karaf.
> I'm -1 for adding it into the scope of Karaf, cause it's plainly out of
> scope. Never the less I think this is quite a handy shell command that
> could be
> quite useful for debugging purposes.
>
> Now my 2 cents about the security stuff, I'm absolutely with Clause, that
> the security system inside Karaf needs some improvments, not all commands
> available should be executable for everyone. So a role-based security
> system is needed here, and it might be even needed to prevent to install
> certain shell commands
> cause they might be of "risk" like the db-commands :)
>
> Regards, Achim
>
> 2012/1/15 Andreas Pieber<an...@gmail.com>
>
>> Well, TBH as long as we do not lay down our roadmap what we expect from
>> Karaf's application service security (although Claus wrote down quite a
>> detailed idea :-)) I somehow have the feeling that this is the wrong thread
>> for a discussion about the security of those commands.
>> -->
>> @Commands: I still think that they'll better fit into other projects. I
>> would like to wait some days what the Aries guys think about the proposal
>> (I'll answer there too later today). Independently I like the idea of some
>> kind of Karaf-Team-Maintained-Enterprise-Command-Repository. Maybe we could
>> host it at github since it's ways fast to release/maintain there. We can
>> use the Karaf lists and issue tracker to work on them but have more
>> freedom. E.g. github.com/karaf or karaf-extras. If we allow only
>> contributions for ppl signed the CLA or via the Karaf issue tracker we
>> could in addition move those projects freely to karaf if we feel they're
>> ready for the core or a sub-project.
>> @Security: maybe start a new thread based on Claus's suggestions. I think
>> this could be a good target for Karaf-3.x/4.x (depending on how deep we
>> need to cut into Karaf for the various changes.
>>
>> Kind regards,
>> Andreas
>>
>> 2012/1/15 Łukasz Dywicki<lu...@code-house.org>
>>
>>>
>>> In reply to Claus Ibsen mail
>>>> Well there is a problem, if anyone who can ssh into karaf, can execute
>>>> any arbitrary SQL against any data sources deployed, and being able to
>>>> hide using the credentials from the application level data source. If
>>>> the user would always have to provide a username/password when
>>>> executing the SQL using the Karaf commands, then that is better.
>>>
>>> We can introduce a multiple roles and then operator can grant access to
>>> execute given command group. OSGi PermissionAdmin is another place which
>>> can be involved in security checks.
>>>
>>> Best regards,
>>> Łukasz Dywicki
>>> --
>>> Code-House
>>> http://code-house.org
>>>
>>>
>>
>
>
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Database commands for Karaf
Posted by Achim Nierbeck <bc...@googlemail.com>.
Hi,
I pretty much liked the idea of Claus, that a "app-store" kind-of-thing
could be the home for such neat shell/other-stuff improvments on top of
Karaf.
I'm -1 for adding it into the scope of Karaf, cause it's plainly out of
scope. Never the less I think this is quite a handy shell command that
could be
quite useful for debugging purposes.
Now my 2 cents about the security stuff, I'm absolutely with Clause, that
the security system inside Karaf needs some improvments, not all commands
available should be executable for everyone. So a role-based security
system is needed here, and it might be even needed to prevent to install
certain shell commands
cause they might be of "risk" like the db-commands :)
Regards, Achim
2012/1/15 Andreas Pieber <an...@gmail.com>
> Well, TBH as long as we do not lay down our roadmap what we expect from
> Karaf's application service security (although Claus wrote down quite a
> detailed idea :-)) I somehow have the feeling that this is the wrong thread
> for a discussion about the security of those commands.
> -->
> @Commands: I still think that they'll better fit into other projects. I
> would like to wait some days what the Aries guys think about the proposal
> (I'll answer there too later today). Independently I like the idea of some
> kind of Karaf-Team-Maintained-Enterprise-Command-Repository. Maybe we could
> host it at github since it's ways fast to release/maintain there. We can
> use the Karaf lists and issue tracker to work on them but have more
> freedom. E.g. github.com/karaf or karaf-extras. If we allow only
> contributions for ppl signed the CLA or via the Karaf issue tracker we
> could in addition move those projects freely to karaf if we feel they're
> ready for the core or a sub-project.
> @Security: maybe start a new thread based on Claus's suggestions. I think
> this could be a good target for Karaf-3.x/4.x (depending on how deep we
> need to cut into Karaf for the various changes.
>
> Kind regards,
> Andreas
>
> 2012/1/15 Łukasz Dywicki <lu...@code-house.org>
>
> >
> > In reply to Claus Ibsen mail
> > > Well there is a problem, if anyone who can ssh into karaf, can execute
> > > any arbitrary SQL against any data sources deployed, and being able to
> > > hide using the credentials from the application level data source. If
> > > the user would always have to provide a username/password when
> > > executing the SQL using the Karaf commands, then that is better.
> >
> > We can introduce a multiple roles and then operator can grant access to
> > execute given command group. OSGi PermissionAdmin is another place which
> > can be involved in security checks.
> >
> > Best regards,
> > Łukasz Dywicki
> > --
> > Code-House
> > http://code-house.org
> >
> >
>
--
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/>
Re: Database commands for Karaf
Posted by Andreas Pieber <an...@gmail.com>.
Well, TBH as long as we do not lay down our roadmap what we expect from
Karaf's application service security (although Claus wrote down quite a
detailed idea :-)) I somehow have the feeling that this is the wrong thread
for a discussion about the security of those commands.
-->
@Commands: I still think that they'll better fit into other projects. I
would like to wait some days what the Aries guys think about the proposal
(I'll answer there too later today). Independently I like the idea of some
kind of Karaf-Team-Maintained-Enterprise-Command-Repository. Maybe we could
host it at github since it's ways fast to release/maintain there. We can
use the Karaf lists and issue tracker to work on them but have more
freedom. E.g. github.com/karaf or karaf-extras. If we allow only
contributions for ppl signed the CLA or via the Karaf issue tracker we
could in addition move those projects freely to karaf if we feel they're
ready for the core or a sub-project.
@Security: maybe start a new thread based on Claus's suggestions. I think
this could be a good target for Karaf-3.x/4.x (depending on how deep we
need to cut into Karaf for the various changes.
Kind regards,
Andreas
2012/1/15 Łukasz Dywicki <lu...@code-house.org>
>
> In reply to Claus Ibsen mail
> > Well there is a problem, if anyone who can ssh into karaf, can execute
> > any arbitrary SQL against any data sources deployed, and being able to
> > hide using the credentials from the application level data source. If
> > the user would always have to provide a username/password when
> > executing the SQL using the Karaf commands, then that is better.
>
> We can introduce a multiple roles and then operator can grant access to
> execute given command group. OSGi PermissionAdmin is another place which
> can be involved in security checks.
>
> Best regards,
> Łukasz Dywicki
> --
> Code-House
> http://code-house.org
>
>
Re: Database commands for Karaf
Posted by Łukasz Dywicki <lu...@code-house.org>.
In reply to Claus Ibsen mail
> Well there is a problem, if anyone who can ssh into karaf, can execute
> any arbitrary SQL against any data sources deployed, and being able to
> hide using the credentials from the application level data source. If
> the user would always have to provide a username/password when
> executing the SQL using the Karaf commands, then that is better.
We can introduce a multiple roles and then operator can grant access to execute given command group. OSGi PermissionAdmin is another place which can be involved in security checks.
Best regards,
Łukasz Dywicki
--
Code-House
http://code-house.org
Re: Database commands for Karaf
Posted by Claus Ibsen <cl...@gmail.com>.
On Sun, Jan 15, 2012 at 1:43 PM, David Jencks <da...@yahoo.com> wrote:
> 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.
>
Well there is a problem, if anyone who can ssh into karaf, can execute
any arbitrary SQL against any data sources deployed, and being able to
hide using the credentials from the application level data source. If
the user would always have to provide a username/password when
executing the SQL using the Karaf commands, then that is better.
As said in some industries, this is a NO GO. All access to the
database must be using personal credentials for human beings. Where as
applications must use application level accounts. And any user must
never use application level to access the database, and vise-versa.
Karaf would have a harder time to get inroads into those industries if
it out of the box, exposed this kind of risk.
> 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
>> <ch...@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/
>
--
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/
Re: Database commands for Karaf
Posted by David Jencks <da...@yahoo.com>.
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
> <ch...@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/
Re: Database commands for Karaf
Posted by Claus Ibsen <cl...@gmail.com>.
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
<ch...@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/