With the TLS socket, all data is encrypted on the wire. The TCP socket though is still clear text. Fortunately some SASL authentication mechanism can also supply encryption capabilities. This is called SSF in SASL terminology.
This patch mandates the use of an SSF capable SASL authentiction mechanism on the TCP socket. This in effect restricts you to a choise between GSSAPI and DIGEST-MD5 as your SASL auth methods (the latter is a user/password based scheme). We also disallow anonymous & plaintext auth methods. If you really want to run the TCP socket in clear text & with anonymous auth, simply turn off SASL altogether. Since TLS already provides encryptiuon, if you run SASL over the TLS socket, we don't place any restrictions on the choice of SASL auth mechanism. On the server side I have removed the 'direction' field of the client object. This was only used on the TLS socket & was intended to track whether the handshake process was waiting to receive or send. Rather than try to set this in various places throughout the daemon code, we simply query the neccessary direction at the one point where we register a FD event handle with poll(). This makes the code clearer to follow & reduces the chance of accidentally messing up the state. The send & receive functions previously would call read vs gnutls_record_recv and write vs gnutls_record_send depending on the type of socket. If there is a SASL SSF layer enabled, we have to first pass the outgoing data through the sasl_encode() API, and pass incoming data through sasl_decode(). So the send/recive APIs have changed a little, to deal with this codec need and thus there is also some more state being tracked per connection - we may have to cache the output for sasl_decode for future calls depending on how much data we need in short term. NB, the SSF layer lets you choose a strength factor from 0 -> a large number and the docs all talk about * 0 = no protection * 1 = integrity protection only * 40 = 40-bit DES or 40-bit RC2/RC4 * 56 = DES * 112 = triple-DES * 128 = 128-bit RC2/RC4/BLOWFISH * 256 = baseline AES This is incredibly misleading. The GSSAPI mechanism in SASL will never report a strength of anything other than 56. Even if it is using triple-DES. The true strength of the GSSAPI/Kerberos impl is impossible to figure out from the SASL apis - you have to trust that the underlying Kerberos impl was compiled with suitably strong ciphers - all modern OS use strong ciphers in Kebreros so I don't think this is a huge issue. If you are truely paranoid though, you always have the option of using TLS (which gives at least 128 bit ciphers, often 256 bit), and then just using Kerberos for auth and ignore the SASL SSF layer. This is an site admin config choice. qemud/internal.h | 17 ++- qemud/qemud.c | 207 +++++++++++++++++++++++++++++------- qemud/remote.c | 97 ++++++++++++++++- src/remote_internal.c | 283 ++++++++++++++++++++++++++++++++++++++++---------- 4 files changed, 503 insertions(+), 101 deletions(-) Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=| -- Libvir-list mailing list Libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
