Re: Adding AF_VSOCK to getaddrinfo(3)

[Florian Weimer <fweimer at redhat dot com>]

On 08/20/2015 04:20 PM, Stefan Hajnoczi wrote:
> On Wed, Aug 19, 2015 at 03:51:05PM +0200, Florian Weimer wrote:
>> On 08/14/2015 04:44 PM, Stefan Hajnoczi wrote:
>>
>>> Represent AF_VSOCK <uint32_t cid, uint32_t port> addresses textually as
>>> node "[vsock:<cid>]" and service "<port>".  For example, cid 2 and port
>>> 80
>>> is written as node "[vsock:2]" and service "80".
>>>
>>> This is close to the IPv6 notation but not a valid IPv6 address, so it's
>>> possible to extend address parsing code to handle the AF_VSOCK case.
>>
>> What's your use case for this functionality?
>>
>> How transparent do you want to the implementation to be?  Returning
>> AF_VSOCK addresses for AF_UNSPEC queries would give instant AF_VSOCK
>> support to many applications, but could also have unforseen security
>> consequences.
> 
> Yes, AF_UNSPEC is exactly the case I'd like to support.

I can see why this is tempting.  We never did that for UNIX domain
sockets, and I think with good reason.

> By extending getaddrinfo(3) to parse vsock addresses, existing utilities
> like wget, netcat, etc can be used over vsock with no changes or minimal
> changes.

There is a fairly ingrained assumption that this is not possible (i.e.,
these tools expect to talk over the network, not to some local service).
 I don't know how AF_VSOCK authentication is implemented (if any), but
with UNIX domain sockets, there is a strong assumption that connection
to such a socket confers some sense of authority.  It will not happen as
part of visiting a random web page (which can load arbitrary URLs and
could access local sockets as well without additional precautions if
this was supported in the name resolution path).

wget and curl would not actually work with that syntax because they
mangle or reject the string before passing it to getaddrinfo.  urllib2
(Python) and LWP (Perl) are not transparent in this regard, either.

mount also does not work:

# mount [vsock:2]/:/export /mnt
mount.nfs: remote share not in 'host:dir' format

There is an obvious fix (get your own TLD and reserve it for this kind
of name resolution), but let's not go there. :-)

> An example is NFS over vsock.  The nfs-utils userspace tools
> mount.nfs(8) program uses getaddrinfo(3) with AF_UNSPEC to resolve a
> hostname string to a sockaddr.  It should be possible to say "mount.nfs
> [vsock:2]:/export /mnt" and it would work just like it does for IPv4 and
> IPv6 today.
> 
> Can you elaborate on the security concerns?

See above, non-IP sockets generally do not have any protection against
the equivalent of cross-site request forgery.

Windows does something remotely similar (conflation between Internet and
Netbios names, and there are UNC path resolution issues as well).  Such
enhancements are difficult to make without endangering existing
applications.

I also expect that some applications will crash if they see anything
else besides AF_INET and AF_INET6 from getaddrinfo if they supply
AF_UNSPEC.  Technically, this is an application bug, but it would still
be annoying to have a denial-of-service bug exposed by a glibc update.

I might be talked into doing this if a new AI_ANY_FAMILY flag is
present.  But you'd still have to patch mount etc. to support that, and
for curl, wget, and maybe even netcat, it would have to be off by
default and enabled by a command line switch.

I can see why this proposal is tempting, but it's too late.  This
enhancement had to be made right when getaddrinfo was introduced.

-- 
Florian Weimer / Red Hat Product Security