-
Bug
-
Resolution: Unresolved
-
Normal
-
None
-
rhel-9.6
-
No
-
None
-
rhel-security-selinux
-
None
-
QE ack
-
False
-
False
-
-
None
-
Red Hat Enterprise Linux
-
None
-
-
None
-
Automated
-
Unspecified
-
Unspecified
-
Unspecified
-
Unspecified
-
None
What were you trying to do that didn't work?
In developing a systemd service that invokes __ systemd-run -t to run a command as another transient service, SELinux prevented systemd-run from invoking the target command in the default SELinux enforcing mode on RHEL 9.6.
Please provide the package NVR for which the bug is seen:
selinux-policy-38.1.53-5.el9_6.noarch
systemd-252-51.el9_6.1.x86_64
How reproducible is this bug?
The bug is reproducible consistently.
Steps to reproduce
- Create a systemd service that invokes systemd-run -t as its ExecStart command:
# cat >/lib/systemd/system/test_avc.service <<EOF
[Service]
ExecStart=/usr/bin/systemd-run -t /usr/bin/true
Type=oneshot
EOF
# systemctl daemon-reload
- Try to start the service:
# systemctl start test_avc
Expected results
The service starts and runs successfully.
Actual results
The service fails to start. Here's the output from systemctl start command, the service status after the failure, and the SELinux AVC denials from the audit log:
# systemctl start test_avc Job for test_avc.service failed because the control process exited with error code. See "systemctl status test_avc.service" and "journalctl -xeu test_avc.service" for details. # systemctl status test_avc × test_avc.service Loaded: loaded (/usr/lib/systemd/system/test_avc.service; static) Active: failed (Result: exit-code) since Tue 2025-09-02 09:54:15 UTC; 3s ago Process: 1652 ExecStart=/usr/bin/systemd-run -t -q /usr/bin/true (code=exited, status=208/STDIN) Main PID: 1652 (code=exited, status=208/STDIN) CPU: 6msSep 02 09:54:15 ip-10-16-44-29.service-discovery.fsapi.com systemd[1]: Starting test_avc.service... Sep 02 09:54:15 ip-10-16-44-29.service-discovery.fsapi.com systemd[1]: test_avc.service: Main process exited, code=exited, status=208/STDIN Sep 02 09:54:15 ip-10-16-44-29.service-discovery.fsapi.com systemd[1]: test_avc.service: Failed with result 'exit-code'. Sep 02 09:54:15 ip-10-16-44-29.service-discovery.fsapi.com systemd[1]: Failed to start test_avc.service. # ausearch -m avc,user_avc ---- time->Tue Sep 2 09:54:15 2025 type=PROCTITLE msg=audit(1756806855.409:103): proctitle="(true)" type=SYSCALL msg=audit(1756806855.409:103): arch=c000003e syscall=254 success=no exit=-13 a0=3 a1=55e8e56156f0 a2=18 a3=0 items=0 ppid=1 pid=1653 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="(true)" exe="/usr/lib/systemd/systemd" subj=system_u:system_r:init_t:s0 key=(null) type=AVC msg=audit(1756806855.409:103): avc: denied { watch watch_reads } for pid=1653 comm="(true)" path="/dev/pts/1" dev="devpts" ino=4 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:devpts_t:s0 tclass=chr_file permissive=0
After changing SELinux to run in permissive mode, the service will start and run successfully (but in addition to the above denial, one more AVC denial appears in the audit log)
# setenforce 0 # systemctl start test_avc # systemctl status test_avc ○ test_avc.service Loaded: loaded (/usr/lib/systemd/system/test_avc.service; static) Active: inactive (dead)Sep 02 09:51:35 ip-10-16-44-29.service-discovery.fsapi.com systemd[1]: test_avc.service: Main process exited, code=exited, status=208/STDIN Sep 02 09:51:35 ip-10-16-44-29.service-discovery.fsapi.com systemd[1]: test_avc.service: Failed with result 'exit-code'. Sep 02 09:51:35 ip-10-16-44-29.service-discovery.fsapi.com systemd[1]: Failed to start test_avc.service. Sep 02 09:54:15 ip-10-16-44-29.service-discovery.fsapi.com systemd[1]: Starting test_avc.service... Sep 02 09:54:15 ip-10-16-44-29.service-discovery.fsapi.com systemd[1]: test_avc.service: Main process exited, code=exited, status=208/STDIN Sep 02 09:54:15 ip-10-16-44-29.service-discovery.fsapi.com systemd[1]: test_avc.service: Failed with result 'exit-code'. Sep 02 09:54:15 ip-10-16-44-29.service-discovery.fsapi.com systemd[1]: Failed to start test_avc.service. Sep 02 09:54:51 ip-10-16-44-29.service-discovery.fsapi.com systemd[1]: Starting test_avc.service... Sep 02 09:54:51 ip-10-16-44-29.service-discovery.fsapi.com systemd[1]: test_avc.service: Deactivated successfully. Sep 02 09:54:51 ip-10-16-44-29.service-discovery.fsapi.com systemd[1]: Finished test_avc.service. # ausearch -m avc,user_avc ... ---- time->Tue Sep 2 09:54:51 2025 type=PROCTITLE msg=audit(1756806891.840:108): proctitle="(true)" type=SYSCALL msg=audit(1756806891.840:108): arch=c000003e syscall=254 success=yes exit=1 a0=3 a1=55e8e55ce980 a2=18 a3=0 items=0 ppid=1 pid=1661 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="(true)" exe="/usr/lib/systemd/systemd" subj=system_u:system_r:init_t:s0 key=(null) type=AVC msg=audit(1756806891.840:108): avc: denied { watch watch_reads } for pid=1661 comm="(true)" path="/dev/pts/1" dev="devpts" ino=4 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:devpts_t:s0 tclass=chr_file permissive=1 ---- time->Tue Sep 2 09:54:51 2025 type=PROCTITLE msg=audit(1756806891.840:109): proctitle="(true)" type=SYSCALL msg=audit(1756806891.840:109): arch=c000003e syscall=257 success=yes exit=4 a0=ffffff9c a1=55e8e55ce980 a2=80102 a3=0 items=0 ppid=1 pid=1661 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=(none) ses=4294967295 comm="(true)" exe="/usr/lib/systemd/systemd" subj=system_u:system_r:init_t:s0 key=(null) type=AVC msg=audit(1756806891.840:109): avc: denied { open } for pid=1661 comm="(true)" path="/dev/pts/1" dev="devpts" ino=4 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:devpts_t:s0 tclass=chr_file permissive=1
A few more observations:
- systemd-run fails only when invoked with the -t option. _ Without this option, the service that invokes _systemd-run starts and runs successfully even in SELinux enforcing mode.
- The Fedora policy was updated in 2022 with rules to fix warnings about the same permissions for chr_files of the user_devpts_t type. In the current case the target context is devpts_t, however, so the rules for user_devpts_t don't apply.
- Querying the policy rules tells the following about the permissions allowed for init_t on chr_files of the devpts_t or user_devpts_t type:
# sesearch -A -s init_t -t devpts_t -c chr_file
allow domain file_type:chr_file map; [ domain_can_mmap_files ]:True
allow init_t devpts_t:chr_file { append ioctl lock read write };
allow init_t file_type:chr_file { getattr relabelfrom relabelto };
# sesearch -A -s init_t -t user_devpts_t -c chr_file
allow domain file_type:chr_file map; [ domain_can_mmap_files ]:True
allow init_t device_node:chr_file { create getattr mounton relabelfrom relabelto setattr };
allow init_t file_type:chr_file { getattr relabelfrom relabelto };
allow init_t ptynode:chr_file { append ioctl lock open read write };
allow init_t user_devpts_t:chr_file { watch watch_reads };
- This RHEL 9.6 issue with systemd-run -t does not reproduce on RHEL 10.0 (with selinux-policy-40.13.26-1.el10.noarch and systemd-257-9.el10_0.1.x86_64) - on RHEL 10.0 the service will start and run successfully without generating AVC denials even in SELinux enforcing mode. The output from the sesearch commands (see 3. above) is identical, so it could be that RHEL 10's newer systemd no longer uses the permissions which cause the problem on RHEL 9.6.
