Re: [Libvir] [patch 9/9] Implement better error reporting [repost]
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>
> User-Agent: Thunderbird 1.5.0.9 (X11/20070212)
> To: Mark McLoughlin <markmc(a)redhat.com>
> CC: "Daniel P. Berrange" <berrange(a)redhat.com>,
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 -=|