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 <ch...@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<ch...@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<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 >>> >> >> > > > -- > 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/>
