On Fri, Feb 23, 2007 at 01:28:36PM +0000, Richard W.M. Jones wrote:

Date: Thu, 22 Feb 2007 14:03:25 +0000 From: "Richard W.M. Jones" <rjones@redhat.com> User-Agent: Thunderbird 1.5.0.9 (X11/20070212) To: Mark McLoughlin <markmc@redhat.com> CC: "Daniel P. Berrange" <berrange@redhat.com>, libvir-list@redhat.com Subject: Re: [Libvir] [patch 9/9] Implement better error reporting

Mark McLoughlin wrote:

...

Doesn't accept() fail if the client fails to send the final ACK? Do we want the daemon to die in that case? Think of an unprivileged user connecting to the system daemon's readonly socket ... you really want to be paranoid about the daemon exiting as it creates the opportunity for unprivileged users to take down guests and networks.

i.e. I'm not sure whether it would be actually possible to exploit it in this way, but I'd tend to be pretty paranoid about any exit point from the daemon.

On a similar topic, does anyone know if gnutls_handshake can be DoS'd by a client running arbitrarily slowly? At the moment if someone (even an untrusted host) makes a TCP connection to libvirtd but then doesn't do anything very much then no one else can connect for the duration. I can partly get around this by checking the IP address of the peer much earlier on (after accept() but before any GnuTLS start-up), but that only solves the problem if we're doing very crude IP-level checks, not user-level certificates from a single IP.

Yes, it can be DOS'd even by a slow connection, or by the client blocking on /dev/random for more bytes, or some such. If the socket itself is in non-blocking mode though, the DOS is avoided - gnutls_handshake() will return with an EAGAIN equivalent. There's another gnutls_get_direction() funtion you can then call to determine whether to poll() for read or write conditions. After poll() completes you can re-call gnutls_handshake() and it'll continue where it left off - it may actually do through this cycle several times because the back & forth conversation for handshake is quite 'chatty'. 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 -=|