Bug 1427553

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.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>

(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