`proc-hidepid.service`: Fixing Systemd related issues
wryMitts opened this issue · comments
This is the script I use to prevent failures on startup when using proc-hidepid.service
I've had this configuration running for over a year now on a server host system, and a slew of server VMs. This is not tested on desktop systems.
sudo groupadd proc
mkdir -p /etc/systemd/system/proc-hidepid.service.d/
echo "[Service]
ExecStart=/bin/mount -o remount,nosuid,nodev,noexec,hidepid=2,gid=proc /proc
" > /etc/systemd/system/proc-hidepid.service.d/override.conf
mkdir -p /etc/systemd/system/systemd-logind.service.d/
echo "[Service]
SupplementaryGroups=proc" > /etc/systemd/system/systemd-logind.service.d/override.conf
mkdir -p /etc/systemd/system/user@.service.d/
echo "[Service]
SupplementaryGroups=proc" > /etc/systemd/system/user@.service.d/override.conf
Issues caused without this configuration, and said fixes, are mentioned here:
systemd/systemd#12955
I am unaware of exactly what security impact this may have, but it stops services from failing when booting.
See referenced commit, I added just now:
,gid=proc
But that doesn't really fix much. Just an additional feature. Users that are members of group proc are then excluded from hidepid protections.
If we use SupplementaryGroups=proc then the logged in user (and all programs stared by it) are excluded from hidepid protections. That's not great, not very helpful on desktop systems where most applications are run by the same user. Might be useful for operating systems where each application runs under its own dedicated user account (such as Android).
I didn't test if this would help if sandbox-app-launcher - Sandboxed Application Launcher; flatpak or something similar was used.
It might be useful for servers because then any (compromised) daemons (such as the web server that usually run under their own dedicated user account) might be no longer able view pids of other users.
If doing this, should use below /lib/system/systemd folder if doing this in the security-misc package and not use /etc.
If we use SupplementaryGroups=proc then the logged in user (and all programs stared by it) are excluded from hidepid protections.
I could not entirely reproduce this with the given configuration, although some PIDs do have an unnecessary subgroup added.
I ran ps aux or ls -la /proc or top as a normal user outside the group proc and observed other user PIDs missing.
I also just tried this on a desktop system and reproduced the same missing PIDs missing in xfce.
I dug deeper and found that proc only gets added to some user services, but not all, found by:
gidOfTheProcGroup=$(cat /etc/group | grep ^proc | cut -d ':' -f 3)
sudo ps afx o user,pid,%cpu,%mem,vsz,rss,tty,stat,start,time,comm,group,gid,supgid | grep $gidOfTheProcGroup
On a server system, only systemd-logind running under the given user had the Proc group added. No other user processes had this group.
I tried on a desktop running xfce4, and got these:
USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND GROUP GID SUPGID
user 1595 0.0 0.1 19224 11008 ? Ss 15:57:23 00:00:00 systemd user 1000 24,25,27,29,30,44,46,108,112,114,116,1000,1002
user 1614 0.0 0.0 39564 7680 ? Ssl 15:57:23 00:00:00 \_ pipewire user 1000 24,25,27,29,30,44,46,108,112,114,116,1000,1002
user 1615 0.0 0.1 687512 12456 ? Ssl 15:57:23 00:00:00 \_ pulseaudio user 1000 24,25,27,29,30,44,46,108,112,114,116,1000,1002
user 1617 0.0 0.0 9672 5248 ? Ss 15:57:23 00:00:00 \_ dbus-daemon user 1000 24,25,27,29,30,44,46,108,112,114,116,1000,1002
user 1766 0.0 0.1 237508 9964 ? Ssl 15:57:25 00:00:00 \_ gvfsd user 1000 24,25,27,29,30,44,46,108,112,114,116,1000,1002
user 1881 0.0 0.1 311624 10716 ? Sl 15:57:26 00:00:00 | \_ gvfsd-t user 1000 24,25,27,29,30,44,46,108,112,114,116,1000,1002
user 1845 0.0 0.2 351408 16924 ? Ssl 15:57:25 00:00:00 \_ gvfs-udisks user 1000 24,25,27,29,30,44,46,108,112,114,116,1000,1002
user 1893 0.0 0.1 159800 8088 ? Ssl 15:57:26 00:00:00 \_ gvfsd-metad user 1000 24,25,27,29,30,44,46,108,112,114,116,1000,1002
user 1930 0.0 0.6 524088 48828 ? Ssl 15:57:26 00:00:00 \_ evolution-s user 1000 24,25,27,29,30,44,46,108,112,114,116,1000,1002
user 1954 0.0 0.3 887972 28228 ? Ssl 15:57:26 00:00:00 \_ evolution-c user 1000 24,25,27,29,30,44,46,108,112,114,116,1000,1002
user 1965 0.0 0.4 743444 32104 ? Ssl 15:57:26 00:00:00 \_ evolution-a user 1000 24,25,27,29,30,44,46,108,112,114,116,1000,1002
user 3185 0.0 0.1 239616 10648 ? Sl 16:14:03 00:00:00 \_ gnome-keyri user 1000 24,25,27,29,30,44,46,108,112,114,116,1000,1002
user 3186 0.0 0.1 239896 12096 ? SLsl 16:14:03 00:00:00 \_ gnome-keyri user 1000 24,25,27,29,30,44,46,108,112,114,116,1000,1002
I had Firefox(debian repo) and Bitwarden (appimage) running, both using their namespaces and user namespaces, and they did not appear as using an extra subgroup. Additional notable items missing the subgroup are gdm-x-session and all subprocesses, notepad, terminal, etc.
It mainly appears that all subprocesses under systemctl status user@1000.service have an extra GID that may be an escape vector to read PIDs.
Perhaps it is possible to drop the extra PID from the subservices launched? I'm not sure but I will try to research it.
https://www.freedesktop.org/software/systemd/man/latest/user@.service.html
Then I guess we should add:
[Service]
SupplementaryGroups=proc
Files should be:
- A)
/usr/lib/systemd/system/systemd-logind.service.d/30_security-misc.conf - B)
/usr/lib/systemd/system/user@.service.d/30_security-misc.conf
Seems like a useful pre-configuration.
As long as proc-hidepid.service (or similar mechanism #157) is not enabled by default anyhow, that should provide advantages only.
(Except if someone is already using proc-hidepid.service who does not require SupplementaryGroups=proc. Experts might want undo this configuration but I doubt many are tinkering with this.)
Can we drop either file A) or file B) and have the same effect? Would be good to know what breaks depending on what file is shipped vs missing.
Interesting. So how exactly is this any different than just dropping in protectproc=yes for all system services? Because since we allow all user services and if this actually whitelists user space applications, isn't this the same behavior as just protectproc'ing system services? I might be missing some details because I have not tested this myself.
Interesting. So how exactly is this any different than just dropping in protectproc=yes for all system services? Because since we allow all user services and if this actually whitelists user space applications, isn't this the same behavior as just protectproc'ing system services? I might be missing some details because I have not tested this myself.
This essentially applies protectproc=yes to all services and user apps except for some listed exceptions in my ps afx command from earlier.
But ProtectProc=yes is useful, maybe it can be applied to the systemctl status user@1000.service underlying unit files too.
A default systemd service hardening would be much desired indeed.
A default systemd service hardening would be much desired indeed.