[patch] UNIX sockets support for lwresd

[Danny Mayer]

This really belongs in bind-workers rather than bind-users. See also below.

On 1/16/2012 9:19 AM, Ilya Bakulin wrote:
> Hi list,
> I'm working on Capsicum security framework [1] for the FreeBSD Project.
> While implementing sandbox mode for some applications like tcpdump, we
> have noticed that sandboxed applications are no longer able to resolve DNS
> names. This happens because each DNS resolving is done by making a
> connection to upstream DNS server.
> So we decided to use lwresd and corresponding library (liblwres) so an
> application will talk only with lwresd daemon on localhost, and lwresd
> will upstream DNS query to another server. This worked better, because now
> an application has to maintain only one opened socket to lwresd daemon,
> instead of opening new one each time DNS resolving happens.
> But this also was not enough. We wanted lwresd to use UNIX domain sockets
> instead of TCP/UDP, this is more effective and secure as long as all
> communication happens on one host.
> Another problem is that original liblwres closes socket after each query
> and recreates it when needed. This is impossible when an application is
> sandboxed, because sockets cannot be created in this state.
> 
> To get rid of these problems, I have modified lwresd, liblwres and also
> libisc:
> 1.1) libisc seems to have basic UNIX stream sockets support, but seems it
> was not finished, because many if() statements only checked if the
> connection type is TCP or UDP. I have added handling of UNIX *datagram*
> sockets to all (I hope so) nessesary places. I needed only datagram
> sockets, not stream, but since UNIX sockets support in libisc seems to be
> unusable anyway, I decided to change the type of socket that is created if
> LWRES_ADDRTYPE_UNIXSOCK is requested.

This breaks O/S's that don't support Unix sockets, specifically Windows.
Please explain why Unix domain sockets are more effective and secure
rather than using localhost with standard sockets. The closing of the
socket and creation of a new one is due the fix for the Kaminsky attack
which presumably is not a problem here if the lightweight resolver is
only used locally.

> 1.2) A socket is not closed after a connection was made and data is
> received. Instead, its descriptor is saved and used later when making
> subsequent queries.
> 1.3) New function lwres_socket_init() that tries to open a connection to
> lwresd daemon. This function is called by an application just before it
> enters sandboxed mode. So later, when it makes a DNS query, it reuses
> existing socket.
> 
> There are still some problems that I wanted to fix after receiving initial
> feedback about my patch.
> 2.1) The library is modified to use UNIX socket _by_default_. As I
> understand it's better to add a support for reading UNIX socket path from
> configuration file. Or at least add such command-line option.

No, please don't do that. At best you should make it a buildable option
but there really should be no need for Unix sockets at all.

> 2.2) When using UNIX datagram sockets, one should create a "client" socket
> to receive replies from server (lib/lwres/context.c, near line 349). I
> wonder where this socket should be closed. What I think is that a context
> structure should be modified to include client socket descriptor, so we
> will be able to close it if we don't need it any more.

As usual with the things like this you should be making calls into the
module to create, update and delete the socket and structure. That's the
standard way we implemented these kinds of structures and methods.

> 2.3) Maybe add a config file switch to prevent lwresd from closing
> communication socket after each use? I.e. make a behaviour described in
> 1.2 optional.

This seems to need overall architectural review rather than just hacking
the code for your specific purpose. I don't have solutions, just questions.

> 
> Thank you in advance for reviewing this work, hope you'll find it useful.
> I'm also CC'ing Robert Watson, Jonathan Anderson and Ben Laurie, who work
> on Capsicum implementation.
> 

I'm not convinced that this is the right approach but I'm sure Michael
or Mark will chime in with their own opinions.

Danny
> [1] http://www.cl.cam.ac.uk/research/security/capsicum/