Mailing list thread: https://lore.kernel.org/selinux/87jz42dj60.fsf@defensec.nl/
pam_selinux has two issues with systemd
technically speaking pam_selinux is PAM but i think we should at least be aware of the issues
why private systemd --user instance domain (why not everything should be treated as entrypoint $SHELL): systemd-user excessive privileges (namespaces):
the biggest aspect of this is mount namepaces/mount --bind
effectively it means that the systemd --user instances might end up needing to create content with system labels
keep in mind that systemd is selinux aware and uses getfilecon/setfiles heavily
in dssp5 I rbacsep exempt the systemd --user instance
this alone seems like a valid reason to have a private domain for systemd --user
Known systemd pam_selinux scenarios:
user@UID.service (PAMName=systemd-user: entry /usr/lib/systemd/systemd)
systemctl --user --machine=kcinimod@.host (PAMName=systemd-user: entry /usr/bin/systemd-stdio-bridge)
this should probably not be using PAMName=systemd-user because systemd-stdio-bridge is not systemd --user (investigate why not use PAMName=systemd-stdio-bridge)
run0 (PAMName=systemd-run0: entry $SHELL)
unspecified: you can run any command with PAMName= in theory
pam_selinux:
Are PAM modules able to determine their (real) PAMName= (PAM stacks are often templated)
Maybe we can add a "tag" option to pam_selinux that we can then optionally reference in SELinux context configuration?
pam_selinux open tag=systemd-user (for /etc/pam.d/systemd-user, PAMName=systemd-user)
system_r:init_t:s0 user_r:systemd_user_t:s0 systemd-user (for /pam.d/systemd-user, PAMName=systemd-user)
pam_selinux open tag=systemd-run0 (for /etc/pam.d/systemd-run0, PAMName=systemd-run0)
system_r:init_t:s0 sysadm_r:sysadm_t:s0 systemd-run0 (for /etc/pam.d/systemd-run0, PAMName=systemd-run0)
;; does not currently exist but hypothesis
pam_selinux open tag=systemd-stdio-bridge (for /etc/pam.d/systemd-stdio-bridge, PAMName=systemd-stdio-bridge)
system_r:init_t:s0 staff_r:systemd_stdio_bridge_t:s0 systemd-stdio-bridge (for /etc/pam.d/systemd-stdio-bridge, PAMName=systemd-stdio-bridge)
pam_selinux close:
resets terminal context on session close (prevcon)
sd-pam runs unprivileged and cannot write terminals owned by others (reset context)
also shows up weird in ps: "sd-pam system_u:system_r:init_t:s0 kcinimod"
pam_close_session.3 clearly states that program needs privileges
why is this issue not solved in PAM where it belongs, or why does systemd not coordinate this with PAM? (is this even something selinux should be worried about?)
su/newrole is not affected by default since su does not change ownership of the terminal? (by default? --pty/--no-pty)
sudo, run0 affected
Mailing list thread: https://lore.kernel.org/selinux/87jz42dj60.fsf@defensec.nl/