Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1932458 - SELinux is preventing login from 'getattr' accesses on the filesystem /.
Summary: SELinux is preventing login from 'getattr' accesses on the filesystem /.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 34
Hardware: x86_64
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:c7f4f32f6d9b6d80f205b2c260c...
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-02-24 16:29 UTC by Matt Fagnani
Modified: 2021-03-16 00:28 UTC (History)
8 users (show)

Fixed In Version: selinux-policy-3.14.7-25.fc34
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-03-16 00:28:58 UTC
Type: ---
Embargoed:

Attachments (Terms of Use)

Description Matt Fagnani 2021-02-24 16:29:59 UTC 
Description of problem:
I was using a Fedora 34 KDE Plasma installation updated to 2021-2-23. I updated to systemd-248~rc2-1.fc34 from https://koji.fedoraproject.org/koji/buildinfo?buildID=1714371 yesterday. I updated to selinux-policy-3.14.7-23.fc34 from https://koji.fedoraproject.org/koji/buildinfo?buildID=1714711 I rebooted. I logged into Plasma 5.21.0 on Wayland. I clicked repeatedly at the bottom-left of the screen to open the Application Launcher to reproduce https://bugs.kde.org/show_bug.cgi?id=424879 plasmashell crashed and didn't restart automatically. I switched to VT3 and logged in as my normal user. The login process was denied getattr on /. This denial happened again when I logged into a VT to reproduce it. I was still able to log in and use the shell.




SELinux is preventing login from 'getattr' accesses on the filesystem /.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that login 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 'login' --raw | audit2allow -M my-login
# semodule -X 300 -i my-login.pp

Additional Information:
Source Context                system_u:system_r:local_login_t:s0-s0:c0.c1023
Target Context                system_u:object_r:fs_t:s0
Target Objects                / [ filesystem ]
Source                        login
Source Path                   login
Port                          <Unknown>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           filesystem-3.14-5.fc34.x86_64
SELinux Policy RPM            selinux-policy-targeted-3.14.7-23.fc34.noarch
Local Policy RPM              selinux-policy-targeted-3.14.7-23.fc34.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 5.11.1-300.fc34.x86_64 #1 SMP Tue
                              Feb 23 14:59:16 UTC 2021 x86_64 x86_64
Alert Count                   2
First Seen                    2021-02-24 11:07:16 EST
Last Seen                     2021-02-24 11:09:39 EST
Local ID                      b1007652-66d0-41ef-8d8c-4e6960e7fa0d

Raw Audit Messages
type=AVC msg=audit(1614182979.383:718): avc:  denied  { getattr } for  pid=2127 comm="login" name="/" dev="dm-0" ino=2 scontext=system_u:system_r:local_login_t:s0-s0:c0.c1023 tcontext=system_u:object_r:fs_t:s0 tclass=filesystem permissive=0


Hash: login,local_login_t,fs_t,filesystem,getattr

Version-Release number of selected component:
selinux-policy-targeted-3.14.7-23.fc34.noarch

Additional info:
component:      selinux-policy
reporter:       libreport-2.14.0
hashmarkername: setroubleshoot
kernel:         5.11.1-300.fc34.x86_64
type:           libreport
Comment 1 Zdenek Pytela 2021-02-24 23:48:18 UTC 
Matt,

What is the dm-o filesystem mounted on? If it is the root filesystem, it should have root_t type:


# ls -Zd /
system_u:object_r:root_t:s0 /

# restorecon -vn /
<>
Comment 2 Matt Fagnani 2021-02-25 02:57:34 UTC 
(In reply to Zdenek Pytela from comment #1)
> Matt,
> 
> What is the dm-o filesystem mounted on? If it is the root filesystem, it
> should have root_t type:
> 
> 
> # ls -Zd /
> system_u:object_r:root_t:s0 /
> 
> # restorecon -vn /
> <>

Zdenek, the dm-0 filesystem is mounted on /, and / does have root_t type. / has inode=2 like in the denial.
ls -Zdil /
2 dr-xr-xr-x. 21 root root system_u:object_r:root_t:s0 4096 Feb  3 00:21 /

I ran sudo restorecon -vn / but no change was shown. I'm unsure why the fs_t type was the target context, but maybe SELinux was operating on the root filesystem level instead of the / directory. I saw this denial 5/5 times when logging into a VT today. I don't remember seeing this denial before though. It might have something to do with systemd 248 as that was the most relevant update I made in the last day or so.

I ran the following commands to allow login to getattr /
sudo ausearch -c 'login' --raw | audit2allow -M my-login
sudo semodule -X 300 -i my-login.pp
No denials were shown when I logged into a VT after that. Thanks.
Comment 3 Zdenek Pytela 2021-02-25 21:30:58 UTC 
I've submitted a Fedora PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/621
Comment 4 Fedora Update System 2021-03-03 10:15:49 UTC 
FEDORA-2021-1cb3d5cac1 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-1cb3d5cac1
Comment 5 Fedora Update System 2021-03-03 15:47:42 UTC 
FEDORA-2021-1cb3d5cac1 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-1cb3d5cac1`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-1cb3d5cac1

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 6 Fedora Update System 2021-03-12 18:57:02 UTC 
FEDORA-2021-1e99f2ed79 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-1e99f2ed79`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-1e99f2ed79

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
Comment 7 Fedora Update System 2021-03-16 00:28:58 UTC 
FEDORA-2021-1e99f2ed79 has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.
Note You need to log in before you can comment on or make changes to this bug.