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
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 / <>
(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.
I've submitted a Fedora PR to address the issue: https://github.com/fedora-selinux/selinux-policy/pull/621
FEDORA-2021-1cb3d5cac1 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-1cb3d5cac1
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.
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.
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.