tincctl patches

[Scott Lamb]

Guus Sliepen wrote:
> On Thu, Nov 08, 2007 at 08:11:41AM -0800, Scott Lamb wrote:
> 
>>>> How would you feel about making the subdirectory by default and possibly
>>>> even having tincd and/or tincctl refuse to start if the permissions are
>>>> too open?
>>> Hm. Maybe. Or we can use the uid in struct xucred, and check whether
>>> it is 0 or the same as tincctl's.
>> Hmm. A bit more research shows:
>>
>> * Linux's situation is quite good - peer credentials, connect() EPERM,
> [...]
>> * BSD's not quite as good - peer credentials (no pids), connect() EPERM
> [...]
>> * Solaris (according to the bind source; I don't have a Solaris machine
> [...]
> 
> Hm. It seems we're being spoiled with Linux.
> 
>> I played with two different options:
>>
>> * have fairly clean code that's fully secure only on Linux and *BSD.
>> (control-socket-credentials-where-available.patch)
>>
>> * a more complex mkdir()+chdir()+stat(".") permission
>> check+bind()+fchdir(oldcwd_fd) scheme that I think is fairly good
>> everywhere. (control-socket-dir.patch) The chdir() is to avoid a race in
>> permission checking the directory. I could have also ensured only
>> root/wheel can write to the directories all the way up to the root, but
>> unfortunately that would have complained about a default OS X
>> installation like my laptop:
>>
>> $ ls -laFd / /var /private /private/var /private/var/run
>> drwxrwxr-t  40 root  admin   1428 Oct 27 16:37 //
>> drwxr-xr-x@  7 root  wheel    238 Oct 25 14:39 /private/
>> drwxr-xr-x@ 28 root  wheel    952 Oct 27 16:01 /private/var/
>> drwxrwxr-x  43 root  daemon  1462 Nov  7 22:58 /private/var/run/
>> lrwxr-xr-x@  1 root  admin     11 Oct 27 16:01 /var@ -> private/var
>>
>> Opinion? Messy as it is, I'm likely to polish control-socket-dir.patch a
>> bit and commit it.
> 
> Ok, that seems the better of the two options. A third option is to do
> an authentication handshake over the control socket. This does not have
> to be full-blown TLS, but something simple like sending the hash of the
> combination of a random string and a secret string from a file that has
> been properly chmod/chowned. It would work like this:
> 
> Client sends: random1 random2
> Servers sends: random3 random4
> Client sends: hash("client" + random1 + random4 + secret)
> Server sends: hash("server" + random3 + random2 + secret)

Ahh, true. That would be trustworthy everywhere, and now that you
mention it, similar to what bind/rndc do (/etc/rndc.key).

> A fourth option is to replace the unix socket with an IPv4 socket which
> is bound to localhost and a port below 1024, because only root is
> allowed to bind sockets to low ports. At least, on Linux :)

Everywhere, I believe. But I'd rather not require the sysadmin to choose
a port or risk conflicting with something else if tinc starts up first.
And I'm not asking for a real <1024 port assignment for use on loopback
only.

Since I've already basically written control-socket-dir.patch, I'm
likely to just use it, or even a pared-down version that instead of
using chdir() just assumes the sysadmin will take care of his/her own
permissions on $LOCALSTATEDIR/run and parents or risk a minor race
condition.

Best regards,
Scott