tincctl patches

[Guus Sliepen]

On Mon, Jul 23, 2007 at 01:50:26PM -0700, Scott Lamb wrote:

> > Great. Signal handlers in libevent seemed to incur a lot of syscall
> > overhead, the control socket can replace all the signals.
> 
> I don't think it's too bad for as often as those signals are passed, but
> I like having clean names, acknowledgment with success or failure, and
> the option to pass a lot more data back and forth.

If you use signal events, apparently libevent sets and resets signal
masks around every select/poll/epoll call on Linux. So even if you don't
trigger the signals, it incurs a lot of overhead when you're sending or
receiving a lot of data.

> > You can do that with a purely textual protocol as well. But I admit that
> > having the length of the message in a fixed size message header makes
> > life a lot easier.
> 
> Yeah, I considered text processing but thought this would be easier -
> particularly when sending big blocks of text back. Maybe that will
> change if sending big chunks of more structured data around. In any
> case, I tried to isolate the protocol to only one function each in
> tincctl.c and control.c.

Well, if the binary protocols works better and/or has easier code than a
textual protocol, then we may even consider to use it for the
inter-tincd protocol in tinc 2.0.

> >> In particular, *BSD's closest equivalent (LOCAL_PEERCRED / struct xucred)
> >> does not support pids.
> > 
> > You want to send a greeting message instead where the daemon sends its
> > own PID back. However, if a malicious user can create a control socket
> > when the real tinc daemon isn't running, then it can send back a
> > different PID than its own, which may cause unintended things to happen.
> > If the administrator does kill -9 `tincctl -n vpn getpid`, then the
> > malicious user could get the administrator to kill the wrong process. If
> > the getpeercred() functionality is not portable, we should probably do
> > specific implementations for each OS instead of a generic implementation
> > that can be subverted.
> 
> Hmm, I guess the default location is /var/run, which is 755 by default.
> So a malicious user couldn't create a socket there, but if tinc has
> already created one then died, they could rebind to it. (I believe UNIX
> domain sockets don't support permissions on most platforms.) Yeah,
> you're right, this patch is no good (at least by itself).
> 
> What about putting the control socket in a dedicated subdirectory with
> locked-down permissions (700)? I believe this is the approach taken by
> several other daemon/client pairs, including saslauthd/libsasl2. The
> malicious user then couldn't bind to the socket at all, which seems
> preferable to just not being able to lie about their pid.

That sounds OK. Well, if the administrator does that, and if tincctl uses
getpeercred() or other working alternatives if the OS supports it, and
falls back to the PID provided by the tincd for those OSes that don't
support it, I think that's the best we can do.

-- 
Met vriendelijke groet / with kind regards,
     Guus Sliepen <guus at tinc-vpn.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://brouwer.uvt.nl/pipermail/tinc-devel/attachments/20070723/486741d3/attachment.pgp