Bug 1723132
| Summary: | SELinux is preventing (systemd) from 'write' accesses on the directory faillock. | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Matt Fagnani <matt.fagnani> |
| Component: | selinux-policy | Assignee: | Lukas Vrabec <lvrabec> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 30 | CC: | dwalsh, kilijanek, lvrabec, mgrepl, plautrba, zpytela |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | abrt_hash:16a8e0f9d7ac99cbfe03d3b854042592061d64508637685f988e47204e7c10ab; | ||
| Fixed In Version: | selinux-policy-3.14.3-40.fc30 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-07-13 01:06:45 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. *** |
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