Red Hat Bugzilla – Bug 1427553
RFE: NFS over AF_VSOCK support in SELinux
Last modified: 2018-10-30 06:01:02 EDT
The virtio-vsock host<->guest communications device is new in RHEL 7.4. It offers a zero-configuration channel between virtual machines and the hypervisor. Sockets use the AF_VSOCK address family (originally introduced by VMware). Services using AF_VSOCK need SELinux policy support. The first of these is NFS over AF_VSOCK (port 2049) for Ceph using nfs-ganesha. There is ongoing work to support kernel nfsd in addition to nfs-ganesha. Additional services like the qemu-guest-agent may be run over AF_VSOCK in the future. Users may wish to write policies for custom services, too. Upstream systemd has AF_VSOCK socket activation support. This may play a role in selinux-policy enablement too. Kernel code: net/vmw_vsock/ (core code in af_vsock.c) Background info: http://qemu-project.org/Features/VirtioVsock
Related BZ for Fedora (rawhide) kernel: 1274868
I hadn't realized VSOCK made it's way into RHEL-7.x. Has anyone done any testing with this in SELinux enforcing mode?
(In reply to Paul Moore from comment #3) > I hadn't realized VSOCK made it's way into RHEL-7.x. Has anyone done any > testing with this in SELinux enforcing mode? IIRC Stefan did and connections are being blocked. I see the Fedora component is kernel instead of selinux-policy. Which one is correct?
(In reply to Ademar Reis from comment #5) > I see the Fedora component is kernel instead of selinux-policy. Which one is > correct? They are both correct in some sense. We need to look at the kernel to see if all of the hooks/controls are in place for AF_VSOCK and then we will almost surely need to update the SELinux policy to grant permissions for the vsock_socket object class. As a bit of an aside, since I last looked at this, we have added the vsock_socket object class to the kernel (see below, present in v4.11-rcX kernels), but more work may be needed. commit da69a5306ab92e07224da54aafee8b1dccf024f6 Author: Stephen Smalley <sds@tycho.nsa.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@tycho.nsa.gov> Signed-off-by: Paul Moore <paul@paul-moore.com>
(In reply to Paul Moore from comment #3) > I hadn't realized VSOCK made it's way into RHEL-7.x. Has anyone done any > testing with this in SELinux enforcing mode? I have not tested SELinux in RHEL-7.x. In Fedora 25 I started hitting avc denials while working on AF_VSOCK kernel nfsd enablement. That caused me to look into SELinux and realize there is missing functionality here.
# uname -a Linux pegas74 4.11.0-10.el7a.x86_64 #1 SMP Wed Jun 21 20:48:03 EDT 2017 x86_64 x86_64 x86_64 GNU/Linux # dmesg | grep vsock [ 1.787711] SELinux: Class vsock_socket not defined in policy. # I know that 4.11 kernel recognizes vsock class. Is vsock class supported by 3.10 kernels which are shipped in RHEL-7.4?
This is a RHEL-7 bug but it depends on a Fedora bug. Is it expected?
There is a sockcreate.c file in selinux-testsuite/tests/extended_socket_class directory, which seems to test whether vsock is supported: # grep -i vsock sockcreate.c { "vsock", AF_VSOCK }, # grep -i vsock /boot/config-3.10.0-693.el7.x86_64 CONFIG_VSOCKETS=m CONFIG_VMWARE_VMCI_VSOCKETS=m CONFIG_VIRTIO_VSOCKETS=m CONFIG_VIRTIO_VSOCKETS_COMMON=m CONFIG_VHOST_VSOCK=m # When the vsock kernel module is not available, an error message appears: # lsmod | grep vsock # ./sockcreate vsock stream default ./sockcreate: socket(vsock/40, stream/1, default/0): Address family not supported by protocol # If the vsock kernel module is available then there is no error message: # lsmod | grep vsock # ./sockcreate vsock stream default # echo $? 0 #
(In reply to Milos Malik from comment #12) > This is a RHEL-7 bug but it depends on a Fedora bug. Is it expected? I added it back then when initial support was being investigated, but there's no reason for it. I'm removing the dependency, thanks for spotting it.
(In reply to Milos Malik from comment #11) > # uname -a > Linux pegas74 4.11.0-10.el7a.x86_64 #1 SMP Wed Jun 21 20:48:03 EDT 2017 > x86_64 x86_64 x86_64 GNU/Linux > # dmesg | grep vsock > [ 1.787711] SELinux: Class vsock_socket not defined in policy. > # > > I know that 4.11 kernel recognizes vsock class. Is vsock class supported by > 3.10 kernels which are shipped in RHEL-7.4? Yes, everything is being backported, or planned to be backported. The full list of BZs related to vsock is: kernel AV_VSOCK - https://bugzilla.redhat.com/show_bug.cgi?id=1291282 kernel vsockmon - https://bugzilla.redhat.com/show_bug.cgi?id=1470219 kernel /proc/net/vsock - https://bugzilla.redhat.com/show_bug.cgi?id=1470203 libpcap - https://bugzilla.redhat.com/show_bug.cgi?id=1464362 tcpdump - https://bugzilla.redhat.com/show_bug.cgi?id=1464390 wireshark - https://bugzilla.redhat.com/show_bug.cgi?id=1464395 NFS (kernel) -- https://bugzilla.redhat.com/show_bug.cgi?id=1294880 NFS client (nfs-utils) -- https://bugzilla.redhat.com/show_bug.cgi?id=1291286
Lukas, assuming we backport the current upstream SELinux/AF_VSOCK object class support, and enable the policy capability, this may have some "interesting" impact on the RHEL-7.x SELinux policy and several new socket object classes are going to start appearing where it was just "socket" previously. Have you played with this at all on Fedora yet? Before we backport this to RHEL-7.x I want to make sure we aren't going to give ourselves a massive policy headache.
*** Bug 1437012 has been marked as a duplicate of this bug. ***
*** Bug 1469533 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:3111