+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 <[email protected]> > On Mon, Jan 16, 2012 at 10:41, Achim Nierbeck <[email protected] > >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 <[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/> > > > -- 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/>
