Bug 2249960 - SELinux is preventing rm from getattr access on the filesystem /.
Summary: SELinux is preventing rm from getattr access on the filesystem /.
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 39
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
: 2257905 (view as bug list)
Depends On:
TreeView+ depends on / blocked
Reported: 2023-11-16 04:03 UTC by Dan Macpherson
Modified: 2024-03-19 13:08 UTC (History)
10 users (show)

Fixed In Version: selinux-policy-39.4-1.fc39
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2024-01-30 04:22:03 UTC
Type: ---

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github fedora-selinux selinux-policy pull 1985 0 None open Allow alsa get attributes filesystems with extended attributes 2023-12-22 16:27:31 UTC

Description Dan Macpherson 2023-11-16 04:03:30 UTC
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.
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
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

Comment 1 Zdenek Pytela 2023-11-16 16:56:00 UTC
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.


Comment 2 Dan Macpherson 2023-11-23 14:52:49 UTC
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?

Comment 3 Zdenek Pytela 2023-11-23 16:05:22 UTC
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.

Comment 4 Dan Macpherson 2023-11-29 15:42:41 UTC
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

Comment 5 Zdenek Pytela 2023-12-22 16:27:31 UTC
No, thank you, I've just submitted a PR to address it.

Comment 6 Zdenek Pytela 2024-01-11 13:53:37 UTC
*** Bug 2257905 has been marked as a duplicate of this bug. ***

Comment 7 Fedora Update System 2024-01-26 23:19:54 UTC
FEDORA-2024-334b3be641 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-334b3be641

Comment 8 Fedora Update System 2024-01-27 02:35:11 UTC
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.

Comment 9 Fedora Update System 2024-01-30 04:22:03 UTC
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.

Comment 10 Bernie Hoefer 2024-03-19 13:00:45 UTC
This problem also affects Fedora 38.  With where Fedora 38 is in its lifecycle, is it worth opening a Bugzilla ticket for it?

Comment 11 Zdenek Pytela 2024-03-19 13:08:19 UTC
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.

Note You need to log in before you can comment on or make changes to this bug.