On Fri, Aug 11, 2017 at 09:23:17AM +0000, Jorgen S. Hansen wrote: > > On Aug 3, 2017, at 12:41 PM, Stefan Hajnoczi <stefa...@redhat.com> wrote: > > > > Hi Jorgen, > > There are 3 sockopts defined in include/uapi/linux/vm_sockets.h that are > > currently not implemented in net/vmw_vsock/af_vsock.c: > > > > * SO_VM_SOCKETS_PEER_HOST_VM_ID > > * SO_VM_SOCKETS_TRUSTED > > * SO_VM_SOCKETS_NONBLOCK_TXRX > > > > I noticed this because SO_VM_SOCKETS_TRUSTED is interesting for > > virtio-vsock. Services listening on AF_VSOCK inside the guest may not > > want arbitrary unprivileged host processes to connect. Instead of > > inventing a new solution I wanted to look into SO_VM_SOCKETS_TRUSTED but > > found it is not implemented in linux.git. > > > > What is the status of these sockets? > > These options were only implemented for ESX host endpoints, so were never > part of the Linux host side support. It looks like they could have been > omitted from vm_sockets.h, when the initial upstreaming was performed. > > On ESX, the equivalent of SO_VM_SOCKETS_TRUSTED, is used for retrieving the > value of s->trusted of a VMCI socket. It cannot be used to mark a socket as > trusted. On Linux, trusted is tied to the CAP_NET_ADMIN capability of the > socket creator. VMCI based vSockets will per default only allow host side > sockets that are trusted, or are created by the same user as the VM, to > communicate with a given VM. This is achieved by per default creating VMs > with the VMCI privilege flag VMCI_PRIVILEGE_FLAG_RESTRICTED. It is possible > to create a VM that isn’t restricted, in which case any host process will be > able to communicate with the VM. > > So it should be straight forward to implement the getsockopt part of > SO_VM_SOCKETS_TRUSTED, since it just needs to return s->trusted.
Currently virtio-vsock does not implement the 'restricted' mode but I'm evaluating using it by default for stronger security. Thanks for your response! Stefan
signature.asc
Description: PGP signature
