RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1788616 - "machinectl shell" fails to execute systemctl command and is slow executing other commands
Summary: "machinectl shell" fails to execute systemctl command and is slow executing o...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: selinux-policy
Version: 8.1
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: 8.3
Assignee: Zdenek Pytela
QA Contact: Milos Malik
URL:
Whiteboard:
: 1833391 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-01-07 15:51 UTC by Renaud Métrich
Modified: 2023-10-06 18:58 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-11-04 01:56:01 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 4661741 0 None None None 2020-01-07 15:52:00 UTC
Red Hat Product Errata RHBA-2020:4528 0 None None None 2020-11-04 01:56:25 UTC

Description Renaud Métrich 2020-01-07 15:51:21 UTC 
Description of problem:

When executing "systemctl" command through "machinectl" (which enables to create a dedicated user session), various AVCs pop up.

Example when executing a machinectl shell for "unconfined_t" user:

Command:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# machinectl shell --uid=<USER> .host /usr/bin/systemctl --user
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

Missing rules:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
module machinectl 1.0;

require {
	type systemd_logind_sessions_t;
	type chkpwd_t;
	type unconfined_t;
	type systemd_systemctl_exec_t;
	type systemd_machined_devpts_t;
	type init_t;
	class file entrypoint;
	class fifo_file write;
	class chr_file { read write };
}

#============= chkpwd_t ==============
allow chkpwd_t systemd_machined_devpts_t:chr_file { read write };

#============= init_t ==============
allow init_t systemd_logind_sessions_t:fifo_file write;

#============= unconfined_t ==============
allow unconfined_t systemd_systemctl_exec_t:file entrypoint;
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------


Other users (staff_t, sysadm_t, ...) cannot execute the command as well, same rule as "unconfined_t" applies.

Additionally, while testing, another not-directly related AVC popped up, related to systemd_machined_t, but I don't know how it was triggered:

-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
#============= systemd_machined_t ==============

#!!!! This avc can be allowed using the boolean 'daemons_dump_core'
allow systemd_machined_t root_t:dir write;
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------


Version-Release number of selected component (if applicable):

selinux-policy-3.14.3-20.el8.noarch


How reproducible:

Always


Steps to Reproduce:
1. Set up a user
2. Execute machinectl as shown above

Actual results:

AVCs


Expected results:

No AVC


Additional info:

machinectl is the only way to perform an operation as another user in a dedicated session (when executing through "sudo", the session of the caller is reused).
Comment 1 Renaud Métrich 2020-01-09 09:45:16 UTC 
I'm increasing the priority/severity because not only "systemctl" is impacted, every command ran through "machinectl shell" is:

In Permissive mode:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# time machinectl shell --uid=staff .host /usr/bin/sleep 1
Connected to the local host. Press ^] three times within 1s to exit session.
...
real	0m2.233s
user	0m0.009s
sys	0m0.011s
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

In Enforcing mode:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
# time machinectl shell --uid=staff .host /usr/bin/sleep 1
Connected to the local host. Press ^] three times within 1s to exit session.
...
real	0m26.690s
user	0m0.018s
sys	0m0.029s
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------


This is due to systemd (init_t) not being able to talk to systemd-logind.

The following custom policy rule allows this:
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------
require {
	type systemd_logind_sessions_t;
	type init_t;
	class fifo_file write;
}

#============= init_t ==============
allow init_t systemd_logind_sessions_t:fifo_file write;
-------- 8< ---------------- 8< ---------------- 8< ---------------- 8< --------

It's unclear to me when the "systemd_machined_devpts_t" AVC pops up.
Comment 2 Milos Malik 2020-01-09 10:05:01 UTC 
25 seconds difference can be caused by a D-bus timeout.
Comment 3 Milos Malik 2020-01-09 10:56:23 UTC 
After removing dontaudit rules, the unconfined user scenario triggers following SELinux denials:
----
type=PROCTITLE msg=audit(01/09/2020 05:36:37.396:660) : proctitle=/usr/sbin/unix_chkpwd test-user chkexpiry 
type=SYSCALL msg=audit(01/09/2020 05:36:37.396:660) : arch=x86_64 syscall=execve success=yes exit=0 a0=0x7fcf7abf47ca a1=0x7ffcf9f1d7a0 a2=0x7fcf7adf7028 a3=0x7fcf85e888e0 items=0 ppid=6445 pid=6446 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=unix_chkpwd exe=/usr/sbin/unix_chkpwd subj=system_u:system_r:chkpwd_t:s0 key=(null) 
type=AVC msg=audit(01/09/2020 05:36:37.396:660) : avc:  denied  { siginh } for  pid=6446 comm=unix_chkpwd scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:chkpwd_t:s0 tclass=process permissive=0 
type=AVC msg=audit(01/09/2020 05:36:37.396:660) : avc:  denied  { read write } for  pid=6446 comm=unix_chkpwd path=/dev/pts/1 dev="devpts" ino=4 scontext=system_u:system_r:chkpwd_t:s0 tcontext=system_u:object_r:systemd_machined_devpts_t:s0 tclass=chr_file permissive=0 
----
type=PROCTITLE msg=audit(01/09/2020 05:36:37.489:665) : proctitle=/usr/sbin/unix_chkpwd test-user chkexpiry 
type=SYSCALL msg=audit(01/09/2020 05:36:37.489:665) : arch=x86_64 syscall=execve success=yes exit=0 a0=0x7fcf7b4037ca a1=0x7ffcf9f1d7a0 a2=0x7fcf7b606028 a3=0x7fcf85e888e0 items=0 ppid=6448 pid=6451 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=unix_chkpwd exe=/usr/sbin/unix_chkpwd subj=system_u:system_r:chkpwd_t:s0 key=(null) 
type=AVC msg=audit(01/09/2020 05:36:37.489:665) : avc:  denied  { siginh } for  pid=6451 comm=unix_chkpwd scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:chkpwd_t:s0 tclass=process permissive=0 
----
type=PROCTITLE msg=audit(01/09/2020 05:36:37.518:670) : proctitle=/usr/lib/systemd/systemd --user 
type=SYSCALL msg=audit(01/09/2020 05:36:37.518:670) : arch=x86_64 syscall=execve success=yes exit=0 a0=0x556269808540 a1=0x5562699a7d70 a2=0x5562699c63c0 a3=0x7fcf860d6ba0 items=0 ppid=1 pid=6448 auid=test-user uid=test-user gid=test-user euid=test-user suid=test-user fsuid=test-user egid=test-user sgid=test-user fsgid=test-user tty=(none) ses=16 comm=systemd exe=/usr/lib/systemd/systemd subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null) 
type=AVC msg=audit(01/09/2020 05:36:37.518:670) : avc:  denied  { siginh } for  pid=6448 comm=systemd scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=process permissive=0 
----
type=PROCTITLE msg=audit(01/09/2020 05:36:37.561:672) : proctitle=(ystemctl) 
type=SYSCALL msg=audit(01/09/2020 05:36:37.561:672) : arch=x86_64 syscall=recvmsg success=yes exit=24 a0=0xa a1=0x7ffcf9f1c810 a2=MSG_DONTWAIT|MSG_CMSG_CLOEXEC a3=0x0 items=0 ppid=1 pid=6445 auid=test-user uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=pts1 ses=15 comm=(ystemctl) exe=/usr/lib/systemd/systemd subj=system_u:system_r:init_t:s0 key=(null) 
type=AVC msg=audit(01/09/2020 05:36:37.561:672) : avc:  denied  { write } for  pid=6445 comm=(ystemctl) path=/run/systemd/sessions/15.ref dev="tmpfs" ino=42262 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:systemd_logind_sessions_t:s0 tclass=fifo_file permissive=0 
----
type=PROCTITLE msg=audit(01/09/2020 05:37:02.460:674) : proctitle=(ystemctl) 
type=SYSCALL msg=audit(01/09/2020 05:37:02.460:674) : arch=x86_64 syscall=execve success=no exit=EACCES(Permission denied) a0=0x5562699accd0 a1=0x556269951840 a2=0x556269a180b0 a3=0x0 items=0 ppid=1 pid=6445 auid=test-user uid=test-user gid=test-user euid=test-user suid=test-user fsuid=test-user egid=test-user sgid=test-user fsgid=test-user tty=pts1 ses=15 comm=(ystemctl) exe=/usr/lib/systemd/systemd subj=system_u:system_r:init_t:s0 key=(null) 
type=AVC msg=audit(01/09/2020 05:37:02.460:674) : avc:  denied  { entrypoint } for  pid=6445 comm=(ystemctl) path=/usr/bin/systemctl dev="vda1" ino=4632541 scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tcontext=system_u:object_r:systemd_systemctl_exec_t:s0 tclass=file permissive=0 
----

Unfortunately, I don't see any D-bus related USER_AVC which would explain the 25 seconds delay.
Comment 4 Renaud Métrich 2020-01-09 11:04:03 UTC 
It's definitely related to DBus, but yes, I didn't see anything else than the "init_t systemd_logind_sessions_t:fifo_file" AVC which is something when systemd tries to contact systemd-logind.
Comment 6 Renaud Métrich 2020-05-09 06:48:01 UTC 
*** Bug 1833391 has been marked as a duplicate of this bug. ***
Comment 7 Pavel Moravec 2020-05-09 07:02:18 UTC 
Isn't this BZ about two independent bugs?

1) Some SELinux problem preventing some particular commands,
2) D-Bus related slow execution of some other commands ?

Usually, I prefer 1:1 matching of bugzilla:bug, but a) I might be wrong in understanding the root cause, b) I am ok with even the current approach, if both 1) and 2) will be resolved within this BZ (i.e. QE will verify both scenarios).
Comment 8 Renaud Métrich 2020-05-09 07:20:49 UTC 
Both should be fixed at the same time indeed. The slowness is due to systemd not being able to talk to systemd-logind, causing that 25 seconds timeout.
Comment 24 errata-xmlrpc 2020-11-04 01:56:01 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (selinux-policy bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:4528
Note You need to log in before you can comment on or make changes to this bug.