Bug 2023332

Summary:	selinux-policy: please allow "systemctl --user -M <uid>@ …"
Product:	[Fedora] Fedora	Reporter:	Zbigniew Jędrzejewski-Szmek <zbyszek>
Component:	selinux-policy	Assignee:	Zdenek Pytela <zpytela>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	medium
Version:	35	CC:	dominik, dwalsh, grepl.miroslav, jose.p.oliveira.oss, lvrabec, maxwell, mmalik, omosnace, pkoncity, vmojzis, zpytela
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2021-12-10 15:38:18 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	2020415

Description Zbigniew Jędrzejewski-Szmek 2021-11-15 12:34:33 UTC

Description of problem:
Systemd has a scriptlet which calls 
/usr/lib/systemd/systemd-update-helper user-reload
This fails because selinux denies the call in $subject.

Version-Release number of selected component (if applicable):
selinux-policy-targeted-35.3-1.20211019git94970fc.fc35.noarch

How reproducible:
Deterministic.

Steps to Reproduce:
1. Enable selinux
2. sudo systemctl --user -M $USER@ list-timers

Actual results:
Failed to start transient service unit: Connection reset by peer
Failed to reload daemon: Transport endpoint is not connected

Expected results:
Some list, same as without 'sudo'.

Additional info:
This is being very visible to users, e.g. see
https://ask.fedoraproject.org/t/failed-to-connect-to-bus-invalid-argument/18006.
For now I'll adjust the scriptlet to suppress stderr if selinux is enabled,
but we really need the reload to happen, so I'd appreciate a quick fix.

Comment 1 Zdenek Pytela 2021-11-15 14:21:32 UTC

There seem to be some dontaudited denials triggered by dbus-broker and systemd:

----
type=AVC msg=audit(11/15/2021 08:56:59.167:1097) : avc:  denied  { read write } for  pid=458 comm=dbus-broker path=socket:[37803] dev="sockfs" ino=37803 scontext=system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=1
----
type=AVC msg=audit(11/15/2021 08:56:59.168:1098) : avc:  denied  { read write } for  pid=1 comm=systemd path=socket:[37803] dev="sockfs" ino=37803 scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=1
----
The same for confined users.


Zbyszek, do you happen to know what systemd-stdio-bridge tries to do here?
----
type=PROCTITLE msg=audit(11/15/2021 08:56:59.184:1100) : proctitle=(o-bridge)
type=SYSCALL msg=audit(11/15/2021 08:56:59.184:1100) : arch=x86_64 syscall=ioctl success=no exit=ENOTTY(Inappropriate ioctl for device) a0=0x0 a1=TCGETS a2=0x7ffca74d78a0 a3=0x0 items=0 ppid=1 pid=6580 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=(o-bridge) exe=/usr/lib/systemd/systemd subj=system_u:system_r:init_t:s0 key=(null)
type=AVC msg=audit(11/15/2021 08:56:59.184:1100) : avc:  denied  { ioctl } for  pid=6580 comm=(o-bridge) path=socket:[37803] dev="sockfs" ino=37803 ioctlcmd=TCGETS scontext=system_u:system_r:init_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket permissive=1
----

Comment 2 Zbigniew Jędrzejewski-Szmek 2021-11-15 18:46:28 UTC

See https://github.com/systemd/systemd/pull/17967/commits/1b630835dff5e13046dfd266629f8ff244dc7fb0 for a long explanation.
In short, systemd-stdio-bridge is invoked to connect to a user bus from a privileged context.
The commit message talks about containers, but the description also applies to the host, the
mechanism is the same. So we whole sequence is as follows:
1. dnf invokes rpm
2. a scriptlet is called from rpm
3. the scriptlet calls /usr/lib/systemd/systemd-update-helper
4. systemd-update-helper calls systemctl --user <uid>@ ...
5. in the systemctl binary, sd-bus invokes systemd-run
6. which invokes systemd-stdio-bridge as the user
7. and systemctl communicates with the user manager over the bridge

Comment 3 Zdenek Pytela 2021-11-16 20:16:14 UTC

Thanks for the explanation. The role of dbus-broker is still a bit unclear for me, and I cannot find any package which would call
/usr/lib/systemd/systemd-update-helper user-reload

Anyway the requested permissions are reasonable.
I've submitted a Fedora PR to address the issue:
https://github.com/fedora-selinux/selinux-policy/pull/944

Comment 4 Zbigniew Jędrzejewski-Szmek 2021-11-17 11:58:31 UTC

(In reply to Zdenek Pytela from comment #3)
> Thanks for the explanation. The role of dbus-broker is still a bit unclear
> for me, and I cannot find any package which would call
> /usr/lib/systemd/systemd-update-helper user-reload

It is called from a transfiletrigger in the systemd package, see
https://src.fedoraproject.org/rpms/systemd/blob/rawhide/f/triggers.systemd#_34

> Anyway the requested permissions are reasonable.
> I've submitted a Fedora PR to address the issue:
> https://github.com/fedora-selinux/selinux-policy/pull/944

Thanks!