karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christian Schneider <ch...@die-schneider.net>
Subject Re: Database commands for Karaf
Date Sun, 15 Jan 2012 13:56:29 GMT
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
>> <chris@die-schneider.net>  wrote:
>>> Hi all,
>>>
>>> as part of my Karaf Tutorial about database access I have writte some handy
>>> Karaf shell commands for databases.
>>> They are described with screen dumps in my Tutorial
>>> http://www.liquid-reality.de/x/LYBk .
>>>
>>> Especially for embedded databases like derby and h2 I missed a simple access
>>> to the database for a long time. So I think these commands could be
>>> interesting for many developers.
>>>
>>> So I would like to add them to Karaf and also add a feature for them. Of
>>> course DB commands are not the core domain of Karaf so this is surely
>>> nothing for the Karaf minimal distro but I propose to add them to the
>>> standard distro.
>>>
>>> The reasons are simple:
>>> - I think many people could have use for the commands
>>> - They add no dependencies
>>> - The code is really small (just 16kb)
>>>
>>> Christian
>>>
>>> --
>>> Christian Schneider
>>> http://www.liquid-reality.de
>>>
>>> Open Source Architect
>>> Talend Application Integration Division http://www.talend.com
>>>
>>
>>
>> -- 
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: cibsen@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus, fusenews
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/


-- 

Christian Schneider
http://www.liquid-reality.de

Open Source Architect
Talend Application Integration Division http://www.talend.com


Mime
View raw message