hidepid - hide PIDs owned by other users

Patrick · November 6, 2023, 4:47pm

hidepid is a security feature.

Settings at time of writing:

hidepid=0
hidepid=1
hidepid=2
hidepid=3 - doesn’t seem to exist
hidepid=4

But there are many issues with it:
https://access.redhat.com/solutions/670431

Was discussed and attempted in the past:
https://forums.whonix.org/search?q=hidepid

But never had its own forum thread.

The main issue I remember we had was that pkexec isn’t compatible with hidepid, which broke multiple applications.

pkexec however seems to be the only framework that supports showing a graphical password prompt to escalate parts of a GUI application with administrative (“root”) rights under native Wayland.

Running GUI applications as root, commands such as (lx)sudo gui-application is no longer possible under wayland. (If that works, that is only Xwayland, not native wayland and to be avoided.)

Patrick · November 6, 2023, 6:37pm

github.com/systemd/systemd

stop leaking PIDs, command line arguments, UID, GID through systemctl, D-Bus interface / API - `hidepid` compatibility

opened 06:36PM - 06 Nov 23 UTC

adrelanos

RFE 🎁

### Component systemd ### Is your feature request related to a problem? Please… describe `hidepid` is a security feature. However, even if using `hidepid` and unprivileged run of `systemctl status unit-name` and systemd's D-Bus interface / API. quote https://access.redhat.com/solutions/6704531 > Last problem, that we would like to highlight is potential information leak and false sense of security that hidepid= provides. Information (PID numbers, command line arguments, UID and GID) about system services are tracked by systemd. By default this information is available to everyone to read via systemd's D-Bus interface. When hidepid= option is used systemd doesn't take it into consideration and still exposes all this information at the API level. ### Describe the solution you'd like * Not exposing this information by default. Or a new option to disable exposing this information. * Available to privileged users only (root, capability or group setting). ### Describe alternatives you've considered None. ### The systemd version you checked that didn't have the feature you are asking for _No response_

Patrick · November 7, 2023, 11:15am

hidepid=2,gid=polkitd unfortunately insufficient.

Quote https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=860040

Confirmed, giving access to /proc to polkitd user (running polkitd) is not enough, the authentication agent seems to requires that as well (and granting my user access to /proc denies the interest of hidepid).

Hm, I guess this means you’d have to add your user to that group as well (or rather any user who wants to use polkit). Which sort of defeats the purpose of hidepid=2 to some extent.

Patrick · November 20, 2023, 5:16am

github.com/Kicksecure/security-misc

Hide Proc | New Approach

opened 07:51PM - 19 Nov 23 UTC

monsieuremre

>An optional systemd service mounts /proc with hidepid=2 at boot to prevent user…s from seeing another user's processes. This is >disabled by default because it is incompatible with pkexec. It can be enabled by executing systemctl enable proc-hidepid.service as root. This not only breaks pkexec but breaks a lot of other thing as well and requires manually adding some services into groups that are exepmted from the policy. What we should do is, instead of ```hidepid=2```, we set ```hidepid=4```. > hidepid=ptraceable or hidepid=4 means that procfs should only contain /proc/<pid>/ directories that the caller can ptrace. So basically root processes can access other users stuff, because they can ptrace the processes anyway. But non privileged users/processes are limited. This is a massive improvement from not hiding anything. I did some little testing on Debian on Gnome Wayland and it does not seem to break anything, for now. I suggest we go with this option. massive leap without breakage. This option is also somewhat new. There used to be only 0, 1 and 2. 4 seems to be added recently (in a relative sense). We would need no service for this. We could just remount it the good old way in the secure remount thing. I can add this to the branch, that might get merged as the new secure mounting solution.

Patrick · March 10, 2024, 12:55pm

github.com/Kicksecure/security-misc

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

opened 07:58PM - 04 Mar 24 UTC

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: https://github.com/systemd/systemd/issues/12955 I am unaware of exactly what security impact this may have, but it stops services from failing when booting.

Patrick · March 11, 2024, 3:18pm

github.com/Kicksecure/security-misc

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

opened 03:15PM - 11 Mar 24 UTC

adrelanos

After applying the changes in https://github.com/Kicksecure/security-misc/issues…/208, does `pkexec` work for you? @wryMitts ---- Test command (X11 only compatible, not working in Wayland): pkexec mousepad /tmp/testfile I.e. try running any application with root rights through use of pkexec. (Maybe Wayland compatible.) pkexec nano /tmp/testfile ---- Test command (Wayland compatible, hopefully): sudo apt update sudo apt install gparted gparted ---- related: https://www.kicksecure.com/wiki/Security-misc#hidepid