That's a fair and valid point. I think this needs to be given some thoughts. The problem in that case isn't really to secure karaf itself, but rather the OS file system, which can be used as a gateway to access the file system and execute commands.
On Tue, May 29, 2012 at 11:13 AM, Christian Schneider <[email protected]> wrote: > 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<[email protected]> >>>>> 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 > -- ------------------------ Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ FuseSource, Integration everywhere http://fusesource.com
