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(a)redhat.com&gt; > User-Agent: Thunderbird 1.5.0.9 (X11/20070212) > To: Mark McLoughlin <markmc(a)redhat.com&gt; > CC: "Daniel P. Berrange" <berrange(a)redhat.com&gt;, libvir-list(a)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 -=|