Hide Forgot
Description of problem: Logging into Cockpit as a restricted SELinux user (i. e. not unconfined_u) currently does not work (bug 1727382). One part of that is that restricted user sessions can't start a user systemd instance, and hence also miss a user D-Bus, a user runtime directory ($XDG_RUNTIME_DIR), and related services. Version-Release number of selected component (if applicable): systemd-239-15.el8.x86_64 selinux-policy-3.14.3-8.el8.noarch How reproducible: Always Steps to Reproduce: 1. Create a new user: useradd unpriv; echo 'unpriv:foobar' | chpasswd 2. Change it away from unconfined_u: semanage login -a -s guest_u unpriv 3. log in as that user with ssh: ssh unpriv@localhost 4. check systemd user instance: /usr/bin/systemctl --user status 5. try to use a session/user D-Bus service: busctl --user Actual results: systemd user instance fails to start up: pam_unix(systemd-user:session): session opened for user unpriv by (uid=0) audit: type=1400 audit(1562590486.191:82): avc: denied { signal } for pid=2014 comm="systemd" scontext=guest_u:guest_r:guest_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=process permissive=0 user: Failed with result 'protocol'. Failed to start User Manager for UID 1002. $ /usr/bin/systemctl --user status -bash: /usr/bin/systemctl: Permission denied $ busctl --user Failed to set address: No such file or directory Expected results: This is where I get a bit fuzzy - are users other than unconfined_u *expected* to only have a minimal bare-bones session? I. e. you would never have these use a desktop or Cockpit session, polkit, etc? I. e. is this by design or a bug? Thanks, Martin
*** Bug 1754476 has been marked as a duplicate of this bug. ***
I tested this on a reasonably current RHEL 8.2 nightly instance with selinux-policy-3.14.3-24.el8.noarch, and the test case still fails in exactly the same way. This also still happens on latest Fedora 31.
When I say "test case" I meant the reproducer in the bug description.
I tested this with 'user_u' instead of 'guest_u', and that works. But you said in comment #1 that guest_u should be able to do this as well. If that shouldn't be the case any more, please feel free to reset to verified, of course. Thanks!
The problem with guest_u is that systemctl and busctl do not work in permissive mode: $ id uid=1000(guest-user) gid=1000(guest-user) groups=1000(guest-user) context=guest_u:guest_r:guest_t:s0 $ sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: permissive Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Memory protection checking: actual (secure) Max kernel policy version: 31 $ /usr/bin/systemctl --user status Failed to connect to bus: No such file or directory $ /usr/bin/busctl --user Failed to set address: No such file or directory $ Some changes need to be done in systemd package. # rpm -qa selinux\* systemd\* | sort selinux-policy-3.14.3-24.el8.noarch selinux-policy-targeted-3.14.3-24.el8.noarch systemd-239-19.el8.x86_64 systemd-libs-239-19.el8.x86_64 systemd-pam-239-19.el8.x86_64 systemd-udev-239-19.el8.x86_64 #
Lukas said in bug 1718814 that guest_u is a really restricted role that shouldn't even have network access. So it sounds like the current implementation is fine, and this working with user_u and sysadm_u is sufficient. So I drop the FailedQA again, and I create cockpit test cases for user_u and sysadm_u. Thanks!
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, 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:1773