Bug 1974559

Summary: SELinux policy prevents userfaultfds from being transferred using SCM_RIGHTS
Product: [Fedora] Fedora Reporter: Robert O'Callahan <roc>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED ERRATA QA Contact: Amith <apeetham>
Severity: medium Docs Contact:
Priority: medium    
Version: 34CC: dwalsh, grepl.miroslav, lvrabec, mmalik, omosnace, vmojzis, zpytela
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: selinux-policy-34.22-1.fc34 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 2027660 (view as bug list) Environment:
Last Closed: 2021-10-31 01:14:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
simple reproducer none

Description Robert O'Callahan 2021-06-22 04:02:29 UTC
Created attachment 1792885 [details]
simple reproducer

I have a process that calls userfaultfd() and then passes that fd to another process over a UNIX socket with SCM_RIGHTS. This worked in Fedora 33 but in Fedora 34 it is blocked by the SELinux policy.

I've attached a minimal reproducer. Works with SELinux disabled, fails with SELinux enabled, with:

type=AVC msg=audit(1624334426.556:18021): avc:  denied  { write } for  pid=1271515 comm="test" path="anon_inode:[userfaultfd]" dev="anon_inodefs" ino=7593260 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:unconfined_t:s0 tclass=anon_inode permissive=1

Comment 1 Robert O'Callahan 2021-06-22 04:06:50 UTC
Basically the problem seems to be that the fd is created read/write by the userfaulfd() syscall; then, when we transfer that fd, selinux_file_receive checks that all fd's mode bits are allowed, so it checks for read and write; but Fedora selinux-policy does not allow write for userfaultfd: https://github.com/fedora-selinux/selinux-policy/commit/86327cca3c025dcd3f7b2a4fbe8c2d94c7780e88

I think probably 'write' should be allowed by that policy.

Comment 2 Zdenek Pytela 2021-06-24 08:05:34 UTC
Thank you for the report and details, I've submitted a Fedora PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/789

Comment 3 Ondrej Mosnacek 2021-06-24 15:05:21 UTC
Indeed, the userfaultfds are currently opened with O_RDWR. Yet, I think it should really be O_RDONLY, since the userfaultfd files don't implement the write op. I'll propose a patch to upstream kernel and we'll see what the maintainers think...

Comment 4 Ondrej Mosnacek 2021-06-24 15:28:48 UTC
Kernel patch submitted:
https://lore.kernel.org/linux-fsdevel/20210624152515.1844133-1-omosnace@redhat.com/T/

Comment 7 Robert O'Callahan 2021-07-21 23:14:26 UTC
Thanks for proposing the kernel patch but I see that it was ignored.

Comment 8 Zdenek Pytela 2021-10-18 09:39:39 UTC
As there is still no response in the kernel RFC patch, I've updated the previous PR and backported it:
https://github.com/fedora-selinux/selinux-policy/pull/917

We will see in the future if it is a temporary workaround which can be reverted.

Comment 9 Fedora Update System 2021-10-18 15:43:16 UTC
FEDORA-2021-00891047cf has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-00891047cf

Comment 10 Fedora Update System 2021-10-19 00:48:18 UTC
FEDORA-2021-00891047cf has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-00891047cf`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-00891047cf

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 11 Fedora Update System 2021-10-31 01:14:11 UTC
FEDORA-2021-00891047cf has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.