Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
Description of problem:
Network namespaces when created are mounted in /run/netns.
On RHEL7, 'ip netns add tmp' would get you this:
[root@shale ~]# ip netns add tmp
[root@shale ~]# mount | grep netns
tmpfs on /run/netns type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
proc on /run/netns/tmp type proc (rw,nosuid,nodev,noexec,relatime)
proc on /run/netns/tmp type proc (rw,nosuid,nodev,noexec,relatime)
^^^^
[root@shale ~]# ls -lZ /run/netns/tmp
-r--r--r--. root root system_u:object_r:proc_t:s0 /run/netns/tmp
^^^^^^
However, on Fedora 28 and RHEL8 Beta (and later):
[root@rhel8 ~]# ip netns add tmp
[root@rhel8 ~]# mount | grep netns
tmpfs on /run/netns type tmpfs (rw,nosuid,nodev,seclabel,mode=755)
nsfs on /run/netns/tmp type nsfs (rw,seclabel)
nsfs on /run/netns/tmp type nsfs (rw,seclabel)
^^^^
[root@rhel8 ~]# ls -lZ /run/netns/tmp
-r--r--r--. 1 root root unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 0
Mar 11 10:54 /run/netns/tmp
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Switching to unconfined_t breaks SELinux-confined services using netns with OpenStack.
Version-Release number of selected component (if applicable):
kernel-4.18.0-74.el8.x86_64
iproute-4.18.0-11.el8.x86_64
selinux-policy-3.14.1-61.el8.noarch
selinux-policy-targeted-3.14.1-61.el8.noarch
How reproducible: 100%
Steps to Reproduce:
1. ip netns add tmp
2. ls -lZ /run/netns/tmp
Actual results:
/var/run/netns/tmp is unconfined_t; was proc_t on RHEL7
Expected results:
/var/run/netns/tmp has a security label. For compatibility with existing SELinux policies, proc_t would work.
Additional info:
Doing some digging, I found this:
https://github.com/torvalds/linux/blob/24dce0800baaa508b1a8ccf01ae0a9c8e600a5aa/fs/nsfs.c
I wasn't sure whether this is really an iproute problem (I didn't look at the netns add code path - only the nsfs.c kernel code) or a missing feature in nsfs.c.
It didn't appear that selinux policy concerning nsfs had changed much, and that this was related to using nsfs instead of proc.
The file system isn't the problem here, the security label is.
Ondrej and Lukas pointed out that the calling process (on RHEL8) passes its label to ip netns add, meaning that the /run/netns/XXX is created with the calling process's security label.
That this happens to match up in my synthetic tests with bug 1684885 is not coincidental - and it indicates that the Ocatavia amphora image process called to create the network namespace is also running unconfined.
It should be created with e.g. haproxy_t or some other label used by Octavia within Amphora images.
Description of problem: Network namespaces when created are mounted in /run/netns. On RHEL7, 'ip netns add tmp' would get you this: [root@shale ~]# ip netns add tmp [root@shale ~]# mount | grep netns tmpfs on /run/netns type tmpfs (rw,nosuid,nodev,seclabel,mode=755) proc on /run/netns/tmp type proc (rw,nosuid,nodev,noexec,relatime) proc on /run/netns/tmp type proc (rw,nosuid,nodev,noexec,relatime) ^^^^ [root@shale ~]# ls -lZ /run/netns/tmp -r--r--r--. root root system_u:object_r:proc_t:s0 /run/netns/tmp ^^^^^^ However, on Fedora 28 and RHEL8 Beta (and later): [root@rhel8 ~]# ip netns add tmp [root@rhel8 ~]# mount | grep netns tmpfs on /run/netns type tmpfs (rw,nosuid,nodev,seclabel,mode=755) nsfs on /run/netns/tmp type nsfs (rw,seclabel) nsfs on /run/netns/tmp type nsfs (rw,seclabel) ^^^^ [root@rhel8 ~]# ls -lZ /run/netns/tmp -r--r--r--. 1 root root unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 0 Mar 11 10:54 /run/netns/tmp ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Switching to unconfined_t breaks SELinux-confined services using netns with OpenStack. Version-Release number of selected component (if applicable): kernel-4.18.0-74.el8.x86_64 iproute-4.18.0-11.el8.x86_64 selinux-policy-3.14.1-61.el8.noarch selinux-policy-targeted-3.14.1-61.el8.noarch How reproducible: 100% Steps to Reproduce: 1. ip netns add tmp 2. ls -lZ /run/netns/tmp Actual results: /var/run/netns/tmp is unconfined_t; was proc_t on RHEL7 Expected results: /var/run/netns/tmp has a security label. For compatibility with existing SELinux policies, proc_t would work. Additional info: Doing some digging, I found this: https://github.com/torvalds/linux/blob/24dce0800baaa508b1a8ccf01ae0a9c8e600a5aa/fs/nsfs.c I wasn't sure whether this is really an iproute problem (I didn't look at the netns add code path - only the nsfs.c kernel code) or a missing feature in nsfs.c. It didn't appear that selinux policy concerning nsfs had changed much, and that this was related to using nsfs instead of proc. The file system isn't the problem here, the security label is.