Description of problem: Add SELinux labeling support and access controls for AF_VSOCK sockets. AF_VSOCK is used by QEMU/KVM to support communications between the VM, the host, and other VMs on the system; controlling access to AF_VSOCK based communications is important to ensuring VM separation and controlled sharing.
The Linux v4.11-rcX kernels have basic AF_VSOCK/vsock_socket support (see below), although additional investigation is required to see if that is sufficient. commit da69a5306ab92e07224da54aafee8b1dccf024f6 Author: Stephen Smalley <sds.gov> Date: Mon Jan 9 10:07:30 2017 -0500 selinux: support distinctions among all network address families Extend SELinux to support distinctions among all network address families implemented by the kernel by defining new socket security classes and mapping to them. Otherwise, many sockets are mapped to the generic socket class and are indistinguishable in policy. This has come up previously with regard to selectively allowing access to bluetooth sockets, and more recently with regard to selectively allowing access to AF_ALG sockets. Guido Trentalancia submitted a patch that took a similar approach to add only support for distinguishing AF_ALG sockets, but this generalizes his approach to handle all address families implemented by the kernel. Socket security classes are also added for ICMP and SCTP sockets. Socket security classes were not defined for AF_* values that are reserved but unimplemented in the kernel, e.g. AF_NETBEUI, AF_SECURITY, AF_ASH, AF_ECONET, AF_SNA, AF_WANPIPE. Backward compatibility is provided by only enabling the finer-grained socket classes if a new policy capability is set in the policy; older policies will behave as before. The legacy redhat1 policy capability that was only ever used in testing within Fedora for ptrace_child is reclaimed for this purpose; as far as I can tell, this policy capability is not enabled in any supported distro policy. Add a pair of conditional compilation guards to detect when new AF_* values are added so that we can update SELinux accordingly rather than having to belatedly update it long after new address families are introduced. Signed-off-by: Stephen Smalley <sds.gov> Signed-off-by: Paul Moore <paul>
Closing this as we have basic support already and based on the lack of complaints or RFEs I'm guessing this basic level is sufficient.