Addresses the following AVC denial introduced by systemd 260:
avc: denied { getattr } for pid=16530 comm="cockpit-ws" name="/" dev="pidfs" ino=1 scontext=system_u:system_r:cockpit_ws_t:s0 tcontext=system_u:object_r:pidfs_t:s0 tclass=filesystem permissive=0
systemd 260 refactored internal code to use pidfs in most places which
is the likely cause of the new violation.
Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=2449605
systemd 258 requires this for setting up logind sessions via
pam_systemd.so.
That policy has to be optional, as RHEL 9's SELinux does not yet know
about `pidfs_t`.
Fixes#22219
On RHEL 9 (although only on bootc, curiously), systemd sometimes has
trouble with cleaning up beiboot's temp files:
> avc: denied { remove_name } for pid=1 comm="systemd" name="user-known-hosts" dev="tmpfs" ino=77 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:cockpit_tmp_t:s0 tclass=dir permissive=0
Allow this, this is harmless enough.
Run socket-activated cockpit-session with correct context. By default it
is `init_t`, but that will produce a memfd with the wrong permissions, which
the session cannot read.
Allow cockpit-ws to connect to /run/cockpit/session.
Allow restricted user_t and sysadm_t sessions to communicate (but not
connect) to cockpit-ws through the session unix socket. (Covered by
TestLogin.testSELinuxRestrictedUser)
In Fedora 41, systemd ships a new file
/etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf which is owned by
systemd_conf_t. Allow cockpit-ws to read that, otherwise the whole `ssh`
command fails with a SELinux denial as it can't read that config file.
On Fedora 39 we get this rejection:
avc: denied { read } for comm="cockpit-askpass" name="possible" dev="sysfs"
scontext=system_u:system_r:cockpit_ws_t:s0 tcontext=system_u:object_r:sysfs_t:s0
This also happens for "cockpit-beiboot". Our code doesn't directly
access sysfs (at least not /devices/system/cpu/possible), but glibc
does, and Python somehow inherits this.
There is no harm in letting it read sysfs, and it may even be necessary
for hardware based authentication schemas, so allow it.
This is not enabled yet.
When enabled, this allows spawning cockpit-session via connecting to
/run/cockpit/session. You need to be in the cockpit-wsinstance group to
connect.
SELinux doesn't think that cockpit-session ought to be spawned directly
by systemd, so teach it about that.
So far nothing will run this unit. There are also known problems with
trying to use this arrangement in many scenarios, including with client
certificate authentication. This feature not officially supported yet.
Accordingly, the unit files are only included in the cockpit-tests
package.
Add a proof of concept integration test.
Since cockpit-session has its own selinux label, executing other
(differently-labelled) processes from it is considered to be a privilege
boundary transition, similar to executing a setuid binary.
Because of this, `AT_SECURE` gets set in the auxiliary vector, causing
the libc of the spawned process to enter "secure execution" mode. Among
other things, that causes `secure_getenv()` to return NULL, even if a
particular variable is in the environment.
libsystemd uses `secure_getenv()` to look for the user's D-Bus. If
`AT_SECURE` is set, that will fail, causing `sd_bus_default_user()` to
return `-ENOMEDIUM`. This breaks the Python bridge.
The solution to this problem is to mark the state transition as
`noatsecure`. That makes sense: there's no real scenario where
cockpit-session attacks cockpit-bridge via its environment —
cockpit-session is the (substantially) higher-privileged process here.
Most recent Fedora 37's pam_faillock tries to chown/chmod/etc.
some state files, which requires `CAP_FOWNER`. Grant this, as it's less
dangerous than `CAP_DAC_OVERRIDE`.
See https://github.com/cockpit-project/bots/pull/3974
pam_faillock tries to chown its state files to the target user. That's
legit, so allow this in our policy. Drop the test hack that we've been
dragging around for a while.
systemd is currently enable to clean up the files and directories in
/run/cockpit/tls, but if we add symlinks there, we see
avc: denied { unlink } for pid=1 comm="systemd" name="certificate.source" dev="tmpfs" ino=1410 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:cockpit_var_run_t:s0 tclass=lnk_file permissive=0
Mark cockpit_var_run_t as systemd_private_tmp to make sure systemd has
full permissions to clean these files up.
This permission is required by a cockpit.socket ExecStartPost script
which executes
"systemctl show --property Listen cockpit.socket"
in the cockpit-ws caller domain.
Resolves: rhbz#197918
Picked from https://github.com/fedora-selinux/selinux-policy/commit/95b6d266399
