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 <[email protected]> > 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 > -- 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/>
