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<[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/>
--
Jean-Baptiste Onofré
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
