karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: [HEADS UP] Ssh agent and key authentication support
Date Tue, 29 May 2012 12:32:40 GMT
I doubt that there will be some sort of Virus specialized for Karaf.
The day we have to focus on this is the day we made it ;)
So we should keep the balances here. And right now I don't see that there
is a real need to complicate the way it works right now.
A proper warning is merely enough to catch a real admins attention.

regards, Achim

2012/5/29 Christian Schneider <chris@die-schneider.net>:
> Of course viruses are also able to attack the resources I described but a
> virus needs a vulnerability or some help of the user to spread.
> An open karaf is one of those vulnerabilities.
>
> Christian
>
> Am 29.05.2012 14:10, schrieb Achim Nierbeck:
>
>> Hi Christian,
>>
>> my comments inline :)
>>
>> regards, Achim
>>
>> 2012/5/29 Christian Schneider<chris@die-schneider.net>:
>>>
>>> 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
>>
>> fair enough, though I don't see the threat of opening another door
>> here, there are plenty of viruses out there (especially for windows,
>> that'll find their way to this)
>>
>>> - File shares of the company. Often very sensitive informations
>>
>> I'm unsure about the sensitive inormation, I'm quite sure companies will
>> make sure only certain groups of people have access to parts of the
>> data or all.
>>
>>> - Often access to the HR system of the company with sensitive information
>>> like salary
>>
>> Nope, I don't see this threat.
>>
>>> - Access to online banking
>>
>> Any dev that does use his company PC for this but not his private is
>> doing this in his own responsibility.
>> I don't consider this to be a major threat.
>>
>>> - 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
>>
>> this threat is not more or less then whit std. viruses
>>
>>> 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)
>>
>> that's what firewalls are for, and you have those open doors with
>> internal structures already
>> so no real new threat here.
>>
>>> - 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
>>
>> again, firewalls protect internal structures from external attacks.
>> Internal Attacks are
>> as usual the main issue, and you don't need an Karaf to expose extra
>> threats.
>>
>>> - He can read and write all files in reach of that user. Among these are
>>> the
>>> encrypted passwords mentioned above
>>
>> see 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
>>
>> see above
>>
>>> - He can install software to use the microphone and camera of the machine
>>
>> it's called "Flame" I think ...
>>
>>> 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?
>>
>> I think most of your ideas concerning the threats are there but do not
>> depent on
>> Karaf but mostly on internal infrastructure. So this is an issue for the
>> admins
>> of the company. I don't think Karaf exposes new threats.
>>
>>> 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<gnodet@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
>>>
>>
>>
>
>
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Open Source Architect
> Talend Application Integration Division http://www.talend.com
>



-- 

Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/>
Committer & Project Lead
OPS4J Pax for Vaadin
<http://team.ops4j.org/wiki/display/PAXVAADIN/Home> Commiter & Project
Lead
blog <http://notizblog.nierbeck.de/>

Mime
View raw message