Mailing-List: contact dev-help@karaf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@karaf.apache.org
Received-SPF: pass (nike.apache.org: domain of bcanhome@googlemail.com
 designates 209.85.214.176 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <4FC4C093.4060809@die-schneider.net>
References: 
 <CAEQV+EEguaRY9dvaFS7WcSDmTeP=y_WZHvkyDdB2AjcrPf_+1A@mail.gmail.com>
	<CAEQV+EFyv54tE4zsrXw-rCRrmDna5apcF=f=0HNQSUyQKi4s7A@mail.gmail.com>
	<4FC0CF62.5080305@die-schneider.net>
	<CAEQV+EFGg5HoTeb+WGVyRck-gt9hQMJ0d=jLOfuQiY5HzfEH_A@mail.gmail.com>
	<4FC36B89.2070800@googlemail.com>
	<4FC49338.2070704@die-schneider.net>
	<CAD0r13ccefOWZ7u_xiA25j+FAKs4z+_sEN-gLstYq=_0SsLc9g@mail.gmail.com>
	<4FC4C093.4060809@die-schneider.net>
Date: Tue, 29 May 2012 14:32:40 +0200
Message-ID: 
 <CAD0r13eVzgDnEME+ZNUk5fcnXfJD2TAyF4OZ1-haBNotQYWsAg@mail.gmail.com>
Subject: Re: [HEADS UP] Ssh agent and key authentication support
From: Achim Nierbeck <bcanhome@googlemail.com>
To: dev@karaf.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 m=
e
>>> 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 wil=
l
>>> 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 informati=
on
>>> 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 whi=
ch
>>> 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 ar=
e
>>> the
>>> encrypted passwords mentioned above
>>
>> see above
>>
>>> - He can install a keylogger and get access to other systems the dev lo=
gs
>>> 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 machi=
ne
>>
>> 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 t=
o
>>>> 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 ne=
ed
>>>> to browse
>>>> to the starting page of it.
>>>>
>>>>>> I really like the ssh agent as it allows a very convenient managemen=
t
>>>>>> 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. =A0Beginners won't just understand why they ca=
n't
>>>>> connect to the karaf instance, have to find some documentation, do th=
e
>>>>> manipulation. =A0It 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 optio=
n
>>>>>> 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 privat=
e
>>>>>> 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. =A0That's a go=
od
>>>>> thing to have, I just don't think Karaf has to provide it. =A0 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 wou=
ld
>>>> like.
>>>>
>>>>> And I don't think this proposal is good at production time. =A0People
>>>>> will want to know the key before deployment so that it can be used to
>>>>> actually access the instance. =A0Having 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. =A0Also any solution that wo=
uld
>>>>> involve securing the private key would have to also secure the defaul=
t
>>>>> password in the same way.
>>>>
>>>> +1, yep I do favor KISS also, and this proposal doesn't sound like KIS=
S.
>>>>
>>>>>> Christian
>>>>>>
>>>>>>
>>>>>>
>>>>>> Am 25.05.2012 18:34, schrieb Guillaume Nodet:
>>>>>>>
>>>>>>> So Christian has expressed concerns with the current state:
>>>>>>>
>>>>>>> =A0 "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 mak=
es
>>>>>>> the private key more dangerous is that people might not see this ho=
le
>>>>>>> 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. =A0The main idea was t=
o be
>>>>>>> able in development mode, to easily access remote instances without
>>>>>>> any additional configurations. =A0The private key is used by the
>>>>>>> console
>>>>>>> (when karaf is started with bin/karaf) and also by the bin/client f=
or
>>>>>>> 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 an=
d
>>>>>>> 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 kar=
af
>>>>>>> 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 connec=
t
>>>>>>> to any instance at development time without additional configuratio=
n.
>>>>>>>
>>>>>>> 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 work=
s
>>>>>>>> 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 addi=
ng
>>>>>>>> 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. =A0Possible enhancements also inclu=
de a
>>>>>>>> way to change the "default" key which is used when starting a usua=
l
>>>>>>>> karaf ; however, given I don't think that's much used in real
>>>>>>>> production environment, I think this is quite minor and kinda forc=
e
>>>>>>>> the user to use karaf the "right" way. =A0The first step before
>>>>>>>> putting
>>>>>>>> karaf in prod would be to disallow the default public key and star=
t
>>>>>>>> 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 thi=
ng
>>>>>>>> we can imagine is a su/sudo mode or something similar). =A0I reall=
y
>>>>>>>> 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
>


--=20

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/>