[Libvir] [patch 9/9] Implement better error reporting [repost]

[Daniel P. Berrange]

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