If the majority of dev here is ok with a warning I go with it but let me
explain some scenarios that make me concerned.
First as Guillaume noted already we have to treat the default user
karaf/karaf in the same way as the default private key.
So the argument for a default of an open access to karaf is that it will
just be used on dev machines and is no problem there. So lets examine
what a developer
has access to and uses from its machine:
- Company Mail account, private Mail account
- File shares of the company. Often very sensitive informations
- Often access to the HR system of the company with sensitive
information like salary
- Access to online banking
- Many devs are also admins. So they access production systems. Often
devs have a file with encrypted passwords that they access with a master
password
So these are resources that I think should be protected well.
So what are the risks when running karaf in the default open mode?
- An attacker can access the karaf instance remotely (only has to have
IP access to the machine)
- He can install code from remote sources and run it with the users
priviledges that karaf runs in. Typically this user is the dev user
which in many cases is also local system admin
- He can read and write all files in reach of that user. Among these are
the encrypted passwords mentioned above
- He can install a keylogger and get access to other systems the dev
logs into. This way he will also get the master password for the
encrypted passwords
- He can install software to use the microphone and camera of the machine
So the question is: Do you trust everyone in the local network?
If no then why should it be a good default to have karaf wide open by
default?
Christian
Am 28.05.2012 14:11, schrieb Achim Nierbeck:
+1, and to be honest, since we do have a console which is used going to
be used by most
admins/users where we will prompt some sort of warning we are in a
totally different
position then tomcat. To achieve something the same with tomcat you need
to browse
to the starting page of it.
I really like the ssh agent as it allows a very convenient management of
several instances and requires only the little effort of copying the public
keys
to the authorized keys file.
I think it's too much. Beginners won't just understand why they can't
connect to the karaf instance, have to find some documentation, do the
manipulation. It may take 20 minutes, and people that just want to
give it a try may very well not try that.
So the question is if having a default private key is the only option to
achieve a convenient management. I think we have other options that are
almost as convenient and
pose no security risk.
- One option is to log the public keys on the server instance and provide a
command to allow them to connect (add them to the authorized keys)
- Another option is to provide a command to create a remote instance using
the ssh access to the remote system (similar to fuse fabric). After creating
the instance we could allow to also copy keys. So the instance could be
reached without a password.
- For local access using the client command we could create a private key in
the user dir and add it to the authorized keys at first start of karaf. So
the client
command would work without a password and still be secure.
One good thing about these options is that they also apply to production
instances while the default private key would never be an option there.
What you want is a centralized user management system. That's a good
thing to have, I just don't think Karaf has to provide it. That
could be a subproject, but I'm quite sure there are already good
solutions for that.
I always thought I'm able to achieve this with JAAS, just plugin the
centralized user
management available. Like ActiveDirectory / LDAP or what ever one would
like.
And I don't think this proposal is good at production time. People
will want to know the key before deployment so that it can be used to
actually access the instance. Having to start the instance, wait
until the key is generated so that you can later be able to log in
does not sound like something very easy. Also any solution that would
involve securing the private key would have to also secure the default
password in the same way.
+1, yep I do favor KISS also, and this proposal doesn't sound like KISS.
Christian
Am 25.05.2012 18:34, schrieb Guillaume Nodet:
So Christian has expressed concerns with the current state:
"Currently we create a private key at build time and allow full
access with this key by default. I think this opens a big security
hole. Of course the same is true for the karaf:karaf user. What makes
the private key more dangerous is that people might not see this hole
as easily as the default user. So I think we should not do this.
Instead I propose to create a key at runtime and use it to connect to
the local instance. We could store the generated private key in the
user dir to make sure it is at a safe place."
We had a chat on IRC so I'll try to summarize my thinking as well.
The current state uses a static private key. The main idea was to be
able in development mode, to easily access remote instances without
any additional configurations. The private key is used by the console
(when karaf is started with bin/karaf) and also by the bin/client for
default authentication.
To disable that (which is obviously bad when putting karaf in
production, as I explained in an earlier mail), one has to disable the
line in etc/keys.properties and etc/users.properties.
This is similar to what we had with the default login / password and
hardcoded password in ssh:ssh and bin/client, so I don't really see
that as a real problem.
I propose to add a warning to the console and log when starting karaf
with such a default key enabled (i.e. the default key is available to
log in) instead, so that we could keep the ability to easily connect
to any instance at development time without additional configuration.
Thoughts welcomed.
On Fri, May 18, 2012 at 1:56 PM, Guillaume Nodet<gno...@gmail.com> wrote:
I've just committed a fix for KARAF-1475 in 2.3 branch (I'll backport
it to trunk next week).
This changes the way the ssh authentication default mechanism works to
leverage ssh agent forwarding and key based authentication.
In short, the default ssh and admin:connect command don't use the
karaf/karaf login/password authentication by default, but use the ssh
agent instead.
The default console uses an internal key which is accepted by adding
the public part in etc/authorized_keys and a local ssh agent which
will be used by default when using ssh / admin:connect command.
When connecting from the outside, one should use the ssh agent
forwarding on the client (ssh -l 8101 -A localhost), and that will
allow you to automatically connect to other karaf instances if the key
is supported too.
Basically, what this means is that the usual default (i.e. you don't
have to specify the password anyway) should work in a real environment
where the default password / key has been changed.
One thing I just realized I forgot is to enhance the bin/client script
to also use the same private key by default.
Another thing I found (and need to fix), is that the public key
authentication mechanism does not really check the association between
the key used and the user: i.e. any username can be used with any
known key, which is quite bad. Possible enhancements also include a
way to change the "default" key which is used when starting a usual
karaf ; however, given I don't think that's much used in real
production environment, I think this is quite minor and kinda force
the user to use karaf the "right" way. The first step before putting
karaf in prod would be to disallow the default public key and start
karaf using bin/start instead of bin/karaf.
Note that it currently rely on the 0.7.0-SNAPSHOT of sshd.
I'll fix some of the above things next week, and I then plan to start
working on role based authentication on the shell somehow (one thing
we can imagine is a su/sudo mode or something similar). I really
can't bear the confirmation that are prompted any time you want to do
something with bundles anymore, so I think it's time for something
more powerful and flexible.
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
FuseSource, Integration everywhere
http://fusesource.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
--
Christian Schneider
http://www.liquid-reality.de
Open Source Architect
Talend Application Integration Division http://www.talend.com
