Improve cert support

I'd like the priority of this ticket to be reconsidered (or my faulty reasoning explained to me :-)

Currently I see bcfg2 as usable in settings where there is a very strong centralized administration model, and the exact same set of people have root on all machines, and we trust users not to do things like boot their centrally-managed GNU/Linux box of a Knoppix CD. In practice, at least for the security-paranoid, this would seem to imply mostly servers in a controlled-access server room (as I am doing in my test deployment).

If we go against any of these assumptions, then there is a variety of things that can not be done with any real expectation of security, for example:

• Use the SSHBase plugin. Without better cert support, any host with the bcfg2 server password could get the private keys of any other host, which is arguably a worse result than users being given the choice of accepting a changed host key (in the later case, there is at least a chance that a diligent user will raise that as an issue, possibly revealing a crack)

• Distribute any config files that contain passwords, unless all people with root access on all of the machines which use Bcfg2 are trusted with those passwords

• Since SSL is being used only for encryption, not authentication (i.e. there is no certificate verification), it would seem to be possible for someone to create a bogus Bcfg2 server by knowing only the password, which is available on any Bcfg2 client

The key here is that we need to be able to generate files for particular hosts, and make sure only that host can access that file based on security greater than that provided by NFSv3 or rhosts (IP-based "security").

Lack of this feature would also seem to put Bcfg2 at a competitive disadvantage with other Configuration Management systems, such as cfengine and puppet.

BTW here is a good write-up on cfengine vs ssh vs kerberos authentication

More concrete example

(edited from IRC)

• <djbclark> Say I install Bcfg2 client on a laptop, with the password I gleaned by booting some comp off a CD, disconnect a desktop bcfg2 client from the network (or bring it down remotely by some DOS exploit), set my laptop to use the same IP address, set the MAC address to be the same (I'm pretty sure this is easy to do in software), and connect it to the network... how is the bcfg2 server going to know it's not the desktop?
• <desai> yeah, i guess you can compromise single client data.

Bcfg2 Security Spec Document

In IRC, dclark agreed to author a SecuritySpec? document. This will include ideas from Cfengine, Puppet, and other sources, and also try to make bootstrapping as easy as possible. Initial idea on this is to make bootstrapping a 2-step process, the first step of which requires no user intervention and does not copy over security-sensitive config files, and the separate step of which requires some user interaction (such as entering a one-time server-generated password). In this scenario, there would be an additional property in Cfg/TCheetah :info that would specify if a file is security-sensitive.

Some (lightly edited) #bcfg2 discussion that happened while the logging was down:

• [18:04] <djbclark> desai: were you around with my chat with jacques re: security last night? Unfortunatly ilogger2 has been down since 10/10, just notified the admins.
• [18:05] <desai> nope, i missed that.
• [18:05] <desai> is a plan coalescing?
• [18:06] <djbclark> desai: I'm thinking that it might be possible to use http://pyxmlrpcssh.sourceforge.net/ and SSHbase, and avoid having another set of public/private keys
• [18:06] <djbclark> desai: jacques was advocating SASL (with Kerberos as one of the options), but that doesn't seem to be well supported in terms of python modules.
• [18:07] <desai> yeah, i had been looking at SASL, way back when...
• [18:07] <jacques> did not find any modules either
• [18:08] <jacques> I don't think that a simple C wrapper would be difficult to build, but there are none around (that I have seen)
• [18:08] <desai> i just found http://www-unix.globus.org/mail_archive/python-discuss/2002/Archive/msg00024.html
• [18:08] <djbclark> desai: The nifty thing if pycmlrpcssh works out is that (a) it would reuse existing SSHbase code, (b) As a side-effect SSHBase would also get set up for normal ssh, and (c)you could have an ultra-paranoid level of security using keychain
• [18:08] <desai> globus uses ldap
• [18:08] <desai> djbclark: yeah, that would be great
• [18:09] <djbclark> yes I think I found the same message, and then 2 kerberos modules at the 0.001 level of release... but I'll go take a look...
• [18:09] <jacques> Now would it be possible to specify the security flavor on a connection level?
• [18:09] <jacques> some nodes might not have ssh enabled
• [18:09] <desai> they should not need to
• [18:10] <jacques> maybe cluster nodes
• [18:10] <djbclark> jacques: on the client side you would not need any type of ssh server... if there would be no ssh client installed, there would still be ssh key pair generated for the client, but it would only be used by bcfg2.
• [18:10] <jacques> or machines which do not use open ssh but another version (ie not the same format for the keys)
• [18:11] <jacques> But I really like the idea
• [18:11] <desai> it sounds like python-ldap supports sasl at least with some ciphers..
• [18:12] <jacques> the way sasl works with ldap still requires a public key to be shared
• [18:12] <djbclark> There would not have to be any connection at all between Bcfg2 and Open/Commercial SSH, but if openssh was installed, i think that the python-based SSH2 implementation that pyxmlrpcssh uses could use the same keys
• [18:12] <desai> krb may be a problem, but i would think that would be supported with the lower-level library
• [18:12] <desai> djbclark: or even if openssh isn't installed, the keys should work fine...
• [18:13] <jacques> the key of the server to enable tls
• [18:13] <djbclark> Yes, exactly; openssh is not used in any way by pyxmlrpcssh
• [18:13] <jacques> sound good, but then if there is a bug in this one, you might end up exposing your ssh keys
• [18:14] <djbclark> If there is a bug in what one... the python SSH2 implementation?
• [18:14] <djbclark> (at least there won't be buffer overflows :-)
• [18:14] <jacques> the pyxmlrpcssh
• [18:14] <jacques> hehe
• [18:15] <djbclark> jacques: pyxmlrpcssh is a (thin looking) layer that glues together existing python xmlrpc stuff and a python SSH2 implementation known as paramiko
• [18:16] <desai> the pyxmlrpcssh stuff looks reasonable; since it works using SimpleXMLRPCServer, adapting the client and server shouldn't be hard...
• [18:16] <jacques> ok
• [18:16] <desai> we could make it conditional, particularly if it doesn't require much code mods.
• [18:17] <desai> (run it off of a bcfg2.conf setting/cmdline option
• [18:17] <jacques> protocol =???
• [18:17] <desai> yeah, something like that.
• [18:18] <jacques> the only question might come up when 2 different client request different protocols to the same server
• [18:18] <desai> paramiko is available with ubuntu, so that is a good sign.
• [18:18] <desai> Honestly, that doesn't worry me too much...
• [18:19] <desai> it is an easy enough thing to put in bold at the beginning of the docs.
• [18:19] <desai> and migrating between protocols is easy..
• [18:19] <jacques> unless you have scores of machines
• [18:19] <desai> even if you have scores of machines.
• [18:19] <jacques> you cannot expect all of them to change at the same time
• [18:19] <desai> we've done this before.
• [18:19] <desai> you run two servers in parallel for a time.
• [18:19] <jacques> ohh, ok
• [18:20] <jacques> did not think of that :-(
• [18:20] <desai> we had to do this when we changed from bcfg1 to bcfg2, and when we switched bcfg2 to xmlrpc/https
• [18:22] <desai> pyxmlrpcssh isn't packaged.
• [18:22] <djbclark> Would it be difficult to run 2 protocols simultaneously in the same server instance? The existing code might be useful forever for private network boostrapping operations, where you trust the network anyway (DHCP, TFTP, PXE etc)
• [18:22] <desai> (that not it is a problem for you, danny ;)
• [18:22] <djbclark> :-)
• [18:22] <desai> I wouldn't recommend it.
• [18:23] <jacques> you could always do that in the same way ssh deals with cyphers
• [18:23] <desai> we can probably layer pyxmlrpcssh in without much code modification, but making the server multiple-listener, etc, might be problematic.
• [18:23] <djbclark> desai: I'm guessing the packing for debian would be pretty streightforward... it looks like a streight-ahead pure python module
• [18:23] <djbclark> ah k
• [18:23] * desai presumes the same.
• [18:23] <jacques> you negociate one at the beginning of the com
• [18:23] <desai> that is fine when you control all of the protocols, but when one of them is https, you are kind of out of luck...
• [18:24] <jacques> true
• [18:24] <djbclark> Actually it would probably be possible to have the same security characteristics as with the current implementation with ssh... I mean it also supports password operation.
• [18:25] <desai> i don't follow
• [18:26] <djbclark> When bootstrapping you probably want to be able to have a static "fact" in your system image that will allow it to connect to bcfg2 with some level of security approcimating the current shared password approach, no?
• [18:26] <desai> the current password can stay inside of the interaction as well.
• [18:26] <desai> the best way would be the option to set a client into bootstrapping mode, where it doesn't require bidirectional trust
• [18:26] <djbclark> So you could either have a shared password or a special public key that allows access only to items not marked as secure (assuming we want to have gradations around that)
• [18:27] <desai> something like that...
• [18:28] <djbclark> I was in the process of writing out a discussion draft that had both the SSH2 Key and SSL Cert methods as options with advantages/drawbacks, but if you like the SSH2 stuff enough I can just focus on that and the bootstrapping problem
• [18:29] <desai> i think that is a reasonable start.
• [18:29] <desai> if it is easy enough, we may be able to hack it into 0.8.5pre3.
• [18:29] <desai> if it works the way it looks like, it won't effect anyone using the current method..
• [18:30] <djbclark> The only SSL Cert advantage I could think of was the well-tested code base of OpenSSL... and also that the XMLRPC+SSL server might allow easier interop with non-bcfg2 stuff somehow
• [18:30] <desai> yeah, this is a completely custom wire protocol.
• [18:31] <desai> we certainly need to keep that as an option...

I've exchanged some email with Graham Lee Bevan <graham (dot) bevan (at) ntlworld (dot) com>, the maintainer of pyXMLRPCssh. He writes:

Please feel free to send bug reports and feature requests for
pyXMLRPCssh to me, and I will endeavor to fix/implement.

Here is a write-up claiming that a lot of the points made in cfengine vs ssh vs kerberos authentication are BS.

Results of mailing list RFC: (1) (2)

• Better link to results of mailing list RFC
• IRC Discussion - new implementation ideas

This is now completely implemented with per-client passwords, client uuids (for roving and NATted clients) and server fingerprinting support. It is released in 0.9.3pre3. woo!

Desai wrote some wiki pages:

• Certificate Improvement Development Plan
• Authentication
• NAT HOWTO

Interesting Thread and another with Scary Comments:

TLSLite is so far not really a complete SSL implementation by itself.
It doesn't know how to properly check the signatures on certificate
chains.  It has to use an external module like m2crypto for that. 

and:

Note that TLSLite at the moment doesn't know how to authenticate
certificate chains all by itself without external libraries.  I didn't
look at your code sample closely enough to figure out whether you were
using OpenSSL or M2Crypto in a way that takes care of that. 

There are both Q2 2006, so possible that this has changed.

TLSlite hasn't gotten much work lately, but we don't need certificate chain validation, so we should be ok.