Description of problem: I saw this denial of systemd writing to /var/run/faillock each of two times that I logged into Plasma on X from sddm. The first time the Plasma didn't seem to finish loading properly as it was stuck on the splash screen. After I shutdown the system, I logged into Plasma which started fine but with the same denial. I had run scap-workbench with the PCI-DSS v3 Control Baseline for Fedora profile during the session before the denials started. I generated a remediation bash script which I ran in konsole. There were two rules about failed logins which hadn't passed. Set Deny For Failed Password Attempts xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_deny To configure the system to lock out accounts after a number of incorrect login attempts using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows: add the following line immediately before the pam_unix.so statement in the AUTH section: auth required pam_faillock.so preauth silent deny=6 unlock_time=1800 fail_interval=900 add the following line immediately after the pam_unix.so statement in the AUTH section: auth [default=die] pam_faillock.so authfail deny=6 unlock_time=1800 fail_interval=900 add the following line immediately before the pam_unix.so statement in the ACCOUNT section: account required pam_faillock.so Set Lockout Time for Failed Password Attempts xccdf_org.ssgproject.content_rule_accounts_passwords_pam_faillock_unlock_time To configure the system to lock out accounts after a number of incorrect login attempts and require an administrator to unlock the account using pam_faillock.so, modify the content of both /etc/pam.d/system-auth and /etc/pam.d/password-auth as follows: add the following line immediately before the pam_unix.so statement in the AUTH section: auth required pam_faillock.so preauth silent deny=6 unlock_time=1800 fail_interval=900 add the following line immediately after the pam_unix.so statement in the AUTH section: auth [default=die] pam_faillock.so authfail deny=6 unlock_time=1800 fail_interval=900 add the following line immediately before the pam_unix.so statement in the ACCOUNT section: account required pam_faillock.so The remediation script changed settings about failed logins as described above, and so the writes to /var/run/faillock started on the following login. SELinux is preventing (systemd) from 'write' accesses on the directory faillock. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that (systemd) should be allowed write access on the faillock directory 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 '(systemd)' --raw | audit2allow -M my-systemd # semodule -X 300 -i my-systemd.pp Additional Information: Source Context system_u:system_r:init_t:s0 Target Context system_u:object_r:faillog_t:s0 Target Objects faillock [ dir ] Source (systemd) Source Path (systemd) Port <Unknown> Host (removed) Source RPM Packages Target RPM Packages Policy RPM selinux-policy-3.14.3-39.fc30.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Enforcing Host Name (removed) Platform Linux (removed) 5.1.12-300.fc30.x86_64 #1 SMP Wed Jun 19 15:19:49 UTC 2019 x86_64 x86_64 Alert Count 1 First Seen 2019-06-23 01:15:57 EDT Last Seen 2019-06-23 01:15:57 EDT Local ID 9c8be8a7-e34f-479a-8c7a-13b540750281 Raw Audit Messages type=AVC msg=audit(1561266957.146:283): avc: denied { write } for pid=1171 comm="(systemd)" name="faillock" dev="tmpfs" ino=26855 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:faillog_t:s0 tclass=dir permissive=0 Hash: (systemd),init_t,faillog_t,dir,write Version-Release number of selected component: selinux-policy-3.14.3-39.fc30.noarch Additional info: component: selinux-policy reporter: libreport-2.10.0 hashmarkername: setroubleshoot kernel: 5.1.12-300.fc30.x86_64 type: libreport
I ran the following to allow the denial of systemd writing to faillock from VT2 sudo ausearch -c '(systemd)' --raw | audit2allow -M my-systemd sudo semodule -X 300 -i my-systemd.pp sudo systemctl restart sddm I logged into Plasma on X from sddm which froze again. sudo ausearch -m AVC -ts today showed the following denial type=AVC msg=audit(1561271692.725:495): avc: denied { add_name } for pid=4243 comm="(systemd)" name="sddm" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:faillog_t:s0 tclass=dir permissive=0 I repeated the steps above twice, and each time Plasma on X got stuck on the splash screen. The following two denials were shown. type=AVC msg=audit(1561271929.865:547): avc: denied { create } for pid=4680 comm="(systemd)" name="sddm" scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:faillog_t:s0 tclass=file permissive=0 type=AVC msg=audit(1561272064.759:593): avc: denied { setattr } for pid=4973 comm="(systemd)" name="sddm" dev="tmpfs" ino=86576 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:faillog_t:s0 tclass=file permissive=0 I didn't see more denials after that. The my-systemd.te module had the following rules. allow init_t faillog_t:dir { add_name write }; allow init_t faillog_t:file { create setattr }; Plasma on X got stuck on the splash screen after that with a segmentation fault in xembedsniproxy. I'm not sure if that crash was related to the denials above.
Hi Matt, This is quite interesting issue. /usr/bin/sddm should be labeled as xdm_exec_t and running process should be labeled as xdm_t, not init_t. Could you please attach output of: # ps -efZ | grep sddm Are you able to reproduce it? Thanks, Lukas.
Lukas, /usr/bin/sddm is labelled as xdm_exec_t as you mentioned. ls -lZ /usr/bin/sddm -rwxr-xr-x. 1 root root system_u:object_r:xdm_exec_t:s0 849464 May 3 14:46 /usr/bin/sddm The (systemd) process when logging in from sddm was labelled init_t according to the denial messages. ps -efZ | grep sddm showed the following while I was logged into Plasma on Wayland system_u:system_r:xdm_t:s0-s0:c0.c1023 root 1087 1 0 16:36 ? 00:00:00 /usr/bin/sddm system_u:system_r:xserver_t:s0-s0:c0.c1023 root 1102 1087 0 16:36 tty1 00:00:00 /usr/libexec/Xorg -nolisten tcp -auth /var/run/sddm/{27825afc-b93e-455a-b2e2-b25ed6a687d0} -background none -noreset -displayfd 18 -seat seat0 vt1 system_u:system_r:xdm_t:s0-s0:c0.c1023 root 1171 1087 0 16:36 ? 00:00:00 /usr/libexec/sddm-helper --socket /tmp/sddm-auth5fafec92-eb79-4b87-8311-de0aa795e2f7 --id 2 --start /usr/bin/sddm-greeter --socket /tmp/sddm-:0-dxraXD --theme /usr/share/sddm/themes/01-breeze-fedora --user sddm --greeter unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 sddm 1173 1 0 16:36 ? 00:00:00 /usr/lib/systemd/systemd --user system_u:system_r:init_t:s0 sddm 1175 1173 0 16:36 ? 00:00:00 (sd-pam) unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 sddm 1180 1173 0 16:36 ? 00:00:00 /usr/bin/pulseaudio --daemonize=no system_u:system_r:xdm_t:s0-s0:c0.c1023 sddm 1181 1171 0 16:36 ? 00:00:01 /usr/bin/sddm-greeter --socket /tmp/sddm-:0-dxraXD --theme /usr/share/sddm/themes/01-breeze-fedora unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 sddm 1204 1173 0 16:36 ? 00:00:00 /usr/bin/dbus-broker-launch --scope user unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 sddm 1207 1204 0 16:36 ? 00:00:00 dbus-broker --log 4 --controller 11 --machine-id 5ef7d3b6ef4345eab2110bb112fef3e9 --max-bytes 100000000000000 --max-fds 25000000000000 --max-matches 5000000000 unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 sddm 1246 1180 0 16:36 ? 00:00:00 /usr/libexec/pulse/gconf-helper unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 sddm 1247 1173 0 16:36 ? 00:00:00 /usr/libexec/gconfd-2 system_u:system_r:xdm_t:s0-s0:c0.c1023 root 1291 1087 0 16:36 ? 00:00:00 /usr/libexec/sddm-helper --socket /tmp/sddm-auth5fafec92-eb79-4b87-8311-de0aa795e2f7 --id 1 --start dbus-run-session /usr/bin/startplasmacompositor --user matt The (sd-pam) process was labelled init_t so perhaps that was involved since the changes that led to the denials involved pam. I ran sudo semodule -X 300 -r my-systemd. I rebooted and logged into Plasma on X from sddm. Plasma started alright, but the first denial was shown in the journal and setroubleshooter again as follows. type=AVC msg=audit(1562101148.752:291): avc: denied { write } for pid=1193 comm="(systemd)" name="faillock" dev="tmpfs" ino=24553 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:faillog_t:s0 tclass=dir permissive=0 Thanks for looking into this issue.
commit 0bc9fb36e645bcdb51a9d91dcfc4822bf759a21f (HEAD -> rawhide) Author: Lukas Vrabec <lvrabec> Date: Wed Jul 3 17:00:17 2019 +0200 Allow systemd labeled as init_t domain to read/write faillog_t. BZ(1723132)
FEDORA-2019-9c513c4cf8 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2019-9c513c4cf8
I updated to 3.14.3-40 from koji. I ran sudo semodule -X 300 -r my-systemd , and then I rebooted. When I logged into Plasma on X and Wayland, I saw the same first denial again. type=AVC msg=audit(1562776260.272:283): avc: denied { write } for pid=1182 comm="(systemd)" name="faillock" dev="tmpfs" ino=23307 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:faillog_t:s0 tclass=dir permissive=0 The 0bc9fb36 commit looks like it should allow that write. The my-systemd.te policy I've used to prevent these denials is the following. module my-systemd 1.0; require { type init_t; type faillog_t; class dir { add_name write }; class file { create setattr }; } #============= init_t ============== allow init_t faillog_t:dir { add_name write }; allow init_t faillog_t:file { create setattr };
selinux-policy-3.14.3-40.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2019-9c513c4cf8
selinux-policy-3.14.3-40.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 1752998 has been marked as a duplicate of this bug. ***