Bug 2023332 - selinux-policy: please allow "systemctl --user -M <uid>@ …"
Summary: selinux-policy: please allow "systemctl --user -M <uid>@ …"
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 35
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 2020415
TreeView+ depends on / blocked
 
Reported: 2021-11-15 12:34 UTC by Zbigniew Jędrzejewski-Szmek
Modified: 2021-12-10 15:38 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-12-10 15:38:18 UTC
Type: Bug


Attachments (Terms of Use)

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!


Note You need to log in before you can comment on or make changes to this bug.