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:10:55 GMT
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
>



-- 

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