`proc-hidepid.service`: Fixing Systemd related issues

[wryMitts]

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.

[adrelanos]

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.

[wryMitts]

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

[adrelanos]

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.

[monsieuremre]

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.

[wryMitts]

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.

[monsieuremre]

A default systemd service hardening would be much desired indeed.

[adrelanos]

A default systemd service hardening would be much desired indeed.

• Harden all system services by default #213