RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1427553 - RFE: NFS over AF_VSOCK support in SELinux
Summary: RFE: NFS over AF_VSOCK support in SELinux
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: selinux-policy
Version: 7.4
Hardware: All
OS: Linux
high
unspecified
Target Milestone: rc
: ---
Assignee: Lukas Vrabec
QA Contact: Milos Malik
Mirek Jahoda
URL:
Whiteboard:
: 1437012 1469533 (view as bug list)
Depends On: 1564775
Blocks: 1363787 1469533 1479877
TreeView+ depends on / blocked
 
Reported: 2017-02-28 15:08 UTC by Stefan Hajnoczi
Modified: 2018-10-30 10:01 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
SELinux now supports `extended_socket_class` This update introduces the `extended_socket_class` policy capability that enables a number of new SELinux object classes to support all of the known network socket address families. It also enables the use of separate security classes for Internet Control Message Protocol (ICMP) and Stream Control Transmission Protocol (SCTP) sockets, which were previously mapped to the `rawip_socket` class.
Clone Of:
: 1479877 (view as bug list)
Environment:
Last Closed: 2018-10-30 10:00:04 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2018:3111 0 None None None 2018-10-30 10:01:02 UTC

Description Stefan Hajnoczi 2017-02-28 15:08:17 UTC 
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
Comment 2 Stefan Hajnoczi 2017-03-03 14:16:08 UTC 
Related BZ for Fedora (rawhide) kernel: 1274868
Comment 3 Paul Moore 2017-03-03 16:41:01 UTC 
I hadn't realized VSOCK made it's way into RHEL-7.x.  Has anyone done any testing with this in SELinux enforcing mode?
Comment 5 Ademar Reis 2017-03-10 13:28:45 UTC 
(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?
Comment 7 Paul Moore 2017-03-10 14:41:24 UTC 
(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>
Comment 8 Stefan Hajnoczi 2017-03-15 10:08:05 UTC 
(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.
Comment 11 Milos Malik 2017-07-19 08:37:58 UTC 
# 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?
Comment 12 Milos Malik 2017-07-19 09:02:49 UTC 
This is a RHEL-7 bug but it depends on a Fedora bug. Is it expected?
Comment 13 Milos Malik 2017-07-19 09:30:46 UTC 
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
#
Comment 14 Ademar Reis 2017-07-19 18:56:14 UTC 
(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.
Comment 15 Ademar Reis 2017-07-19 19:00:00 UTC 
(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
Comment 16 Paul Moore 2017-07-21 20:32:40 UTC 
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.
Comment 30 Lukas Vrabec 2018-04-16 14:02:43 UTC 
*** Bug 1437012 has been marked as a duplicate of this bug. ***
Comment 31 Lukas Vrabec 2018-04-16 14:03:44 UTC 
*** Bug 1469533 has been marked as a duplicate of this bug. ***
Comment 35 errata-xmlrpc 2018-10-30 10:00:04 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.