Hide Proc | New Approach
monsieuremre opened this issue · 13 comments
An optional systemd service mounts /proc with hidepid=2 at boot to prevent users 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// 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.
Update: actually there are still some small problems. These are still solveable with same approach we already use here. The exemptions.
But it definetely breaks less stuff. For example, hidepid=2 breaks wayland gnome session. hidepid=4 doesn't. Same applies to login too. So I still think this is the better option we should go with.
hidepid=2 is more strict than hidepid=4, right? In that case, this means the opt-in service would be useful to keep even if we'd manage to set the default to hidepid=4.
What we should do is, instead of hidepid=2, we set hidepid=4.
As a default or opt-in?
Update: actually there are still some small problems. These are still solveable with same approach we already use here.
Which problems?
How to solve?
hidepid=2 is more strict than hidepid=4, right?
Yes. But consider these:
- hidepid=2 breaks gnome, even with the current workarounds you have in place. I managed add some more workarounds for some more services, and then it works. But it still breaks some other stuff in other desktops. It is very fail prone.
- hidepid=4 might not be as strong as hidepid=2, but it is a massive leap. It is really very big. And even by not exempting anything or configuring anything, it does not break almost anything. Gnome and KDE boots up just fine. With wayland, with x, with pipewire, with pulseaudio. No breakage.
Which problems?
How to solve?
The only breakage I observed is, on gnome, the shutdown button does not work. Sudo poweroff still works from the terminal. But GUI won't work. And this can be worked around rather easily with the same approach we have in place for hidepid=2. So let's just change hidepid=2 to hidepid=4 and enable the service by default. I haven't tested pkexec. I am guessing it won't break with hidepid=4.
Actually and actually, I was wrong. Hidepid=2 works well too with the exemptions. Also pkexec works too (as root). Why exactly do we not enable this by default? Anything I am missing?
Btw I still think we should get rid of this service anyway and merge it with the secure remount service.
I didn't do that. I just did the usual. Option gid=proc, and added systemd logind to the group proc. So the user can't see anything actually.
Also pkexec works too (as root).
Can you use user "user" and run applications that use pkexec such as gparted?
(gparted not being superb important but a nice use case to test if pkexec is functional.)
related:
https://forums.whonix.org/t/cannot-use-pkexec/8129
I didn't do that. I just did the usual. Option gid=proc, and added systemd logind to the group proc. So the user can't see anything actually.
That's good then.
So if pkexec isn't broken, I'd be happy to look at a PR.
pkexec works for users with root privileges. It won't work for non-privileged users. Tho I think this might be the case already even without the mount option. The testing I have done was to execute simple commands like "ls", "dir", "cd" as another user, which surely worked. I did no testing with gparted or any other program that uses pkexec. There is a chance they might break, but I can't know without testing.
pkexec works for users with root privileges.
That is kinda an oxymoron. pkexec is supposed to be run:
- by non-root users.
- without sudo.
Works with GUI applications under Wayland. (Then no way to run GUI applications as root / with sudo (without Xwayland).)
So the important thing is that pkexec works for non-root users.
Kicksecure, Whonix currently depends on pkexec. Please search the source code on where/how it is used if that interests you. That could also use review / refactoring but getting rid of pkexec (would be nice) should go to different tickets.
Also even if Kicksecure, Whonix would no longer use pkexec it would still be majorly broken if pkexec comparability was broken by this, hence not suitable for enabling by default.
It won't work for non-privileged users. Tho I think this might be the case already even without the mount option. The testing I have done was to execute simple commands like "ls", "dir", "cd" as another user, which surely worked. I did no testing with gparted or any other program that uses pkexec. There is a chance they might break, but I can't know without testing.
So more work required here.
That is kinda an oxymoron. pkexec is supposed to be run:
Will test. If this works with hidepid=4, then we might just do that.
Yes unfortunately pkexec for normal users won't work in any case. Closing.