I'm getting a weird AVC message on a freshly installed Fedora 39 system: SELinux is preventing rm from getattr access on the filesystem /. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that rm should be allowed getattr access on the filesystem by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'rm' --raw | audit2allow -M my-rm # semodule -X 300 -i my-rm.pp Additional Information: Source Context system_u:system_r:alsa_t:s0 Target Context system_u:object_r:fs_t:s0 Target Objects / [ filesystem ] Source rm Source Path rm Port <Unknown> Host danslaptop Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-39.1-1.fc39.noarch Local Policy RPM selinux-policy-targeted-39.1-1.fc39.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name danslaptop Platform Linux danslaptop 6.5.11-300.fc39.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Nov 8 22:37:57 UTC 2023 x86_64 Alert Count 1 First Seen 2023-11-16 12:46:00 AEST Last Seen 2023-11-16 12:46:00 AEST Local ID e115ce4d-7525-4d93-8c0a-31c4e7a20806 Raw Audit Messages type=AVC msg=audit(1700102760.194:134): avc: denied { getattr } for pid=1349 comm="rm" name="/" dev="dm-0" ino=2 scontext=system_u:system_r:alsa_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem permissive=0 Hash: rm,alsa_t,fs_t,filesystem,getattr This message usually occurs during the Fedora boot process. Not sure why something with alsa_t context would need to use rm on my root directory, even if to just use getattr. I don't feel comfortable applying a policy module until I know what I'm dealing with here is safe. Reproducible: Always
It actually is that for the rm command with undisclosed arguments, getattr on / at dm-0 is needed which may be perfectly legit, but you are right it's better to understand it first. Please enable full auditing and try to reproduce the problem. https://fedoraproject.org/wiki/SELinux/Debugging#Enable_full_auditing
Thanks, Zdenek. That gives a bit more detail: type=PROCTITLE msg=audit(24/11/23 00:43:55.945:138) : proctitle=/bin/rm -rf /var/lib/alsa/card3.conf.d type=SYSCALL msg=audit(24/11/23 00:43:55.945:138) : arch=x86_64 syscall=fstatfs success=no exit=EACCES(Permission denied) a0=0x3 a1=0x7ffe009d5e10 a2=0xf a3=0x4 items=0 ppid=1346 pid=1347 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=rm exe=/usr/bin/rm subj=system_u:system_r:alsa_t:s0 key=(null) type=AVC msg=audit(24/11/23 00:43:55.945:138) : avc: denied { getattr } for pid=1347 comm=rm name=/ dev="dm-0" ino=2 scontext=system_u:system_r:alsa_t:s0 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem permissive=0 Seems like it's trying to remove an alsa config. Seems somewhat benign. Still hesitant about allowing a local policy on rm for my root directory. What do you think I should do?
A PATH record was not a part of the audit log? It's just the statfs() syscall. Let's try a local module: # cat local_alsa_rm.cil (allow alsa_t fs_t (filesystem (getattr))) # semodule -i local_alsa_rm.cil and reproduce if there are any additional denials.
Hi Zdenek, Installed the module you mentioned and tried reproducing today. I don't seem to get the alert anymore. Is there anything else I should test out? - Dan
No, thank you, I've just submitted a PR to address it.
*** Bug 2257905 has been marked as a duplicate of this bug. ***
FEDORA-2024-334b3be641 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-334b3be641
FEDORA-2024-334b3be641 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-334b3be641` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-334b3be641 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-334b3be641 has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
This problem also affects Fedora 38. With where Fedora 38 is in its lifecycle, is it worth opening a Bugzilla ticket for it?
I've created a new backport batch. Just note it is not safe to comment on bugs in POST state and later as it is easily overlooked.