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 <[email protected]> wrote: > On Sun, Jan 15, 2012 at 2:56 PM, Christian Schneider > <[email protected]> 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 >>>> <[email protected]> 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: [email protected] >>>> 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: [email protected] > 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
