grsecurity forums

I've just hit freedesktop bug 65575.
Any workaround exists on how to use systemd without loosing proc restriction benefits? Maybe a process exception?

Thx:
Dw

A solution to this query can be found in these bug reports:
https://bugs.gentoo.org/show_bug.cgi?id=472098
https://bugs.gentoo.org/show_bug.cgi?id=455938
Polkitd must be added to the proc restricted group in grsec kernel config. Gdm must be also added in case of 3.6. Gdm-3.8 seems to do fine without it.
I hope it helps for others like me.

Regards: Dw.

Hi,

Can you try the following patch and let me know if it works around the issue?
http://grsecurity.net/~spender/systemd.diff

If it doesn't could you give me the /proc/pid/status contents for the process trying to access /proc/1/cgroup?

Thanks,
-Brad

I've added polkitd to the group configured for CONFIG_GRKERNSEC_PROC_GID and it seems to do the trick.
Thanks: Dw.

Hi,

Can you try just the patch above? It shouldn't require you to enable GRKERNSEC_PROC_GROUP or add polkit to any special group.

Thanks,
-Brad

I'm sorry, but I did not have the time lately to test patched systemd. I'm happy, that the system is running after the transition.

Sorry: Dw.

Brad, does the specified patch still need testing or is that done already? I would be willing to test it, if you are still interested.

It does -- I haven't heard back from anyone.

Thanks,
-Brad

Sadly the patch does not resolve the issue here.
[user@localhost ~]$ systemctl suspend
Failed to read /proc/cmdline. Ignoring: Permission denied
Failed to execute operation: Access denied
Failed to start suspend.target: Access denied
[user@localhost ~]$

How do I best catch the "/proc/pid/status contents for the process trying to access /proc/1/cgroup"? The part that worries me is reliably catching the pid of the process that tries to access /proc/1/cgroup.

Either it should already be running, or it will be created in response to your command. In the former case you'd use strace -p, in the latter, strace -f

Maybe filter to just opens with -e open so you don't have to weed through so many logs.

-Brad

I only have a very basic understanding of some things needed to provide the information you are seeking for, so could you give me a broader description how I should I exactly trace that process?
Here is the output of "strace systemctl suspend": http://pastebin.com/DDSCgLSH
I can't find a request to access /proc/1/cgroup there.
When I attach polkitd to strace, I cant find something requesting /proc/1/cgroup either.

Okay I guess I have been sitting too long and did not see the most obvious things. After a break most things make sense again.
Okay "pidof systemctl" does not seem to indicate that systemctl is already running, so we need strace -f to get all calls even from child processes. The strace output I gave was not done using the -f option, I do not know why I did that.
I will retest and give you the output of the strace command. I am pretty sure I also tried the -f option and I could not find any request for /proc/1/cgroup, but I will have to retry.
Currently my system all of the sudden does not boot with the grsec kernels, I get kernel panics on boot because of systemd. I think I kind of understand the frustration of systemd now. Since I have not set up kdump and the traceback is flooding the whole screen posting a photo is not helpful either, so I will wipe the whole partition and start from scratch again.
Thanks Brad for your hard work and your great support.

Hi Alan,

So, there are two accesses here it's assuming can be performed by an unprivileged user: /proc/1/root and /proc/cmdline. The /proc/cmdline one I can fix while retaining the same security benefit as before by essentially providing faked content to unprivileged users which nevertheless contains the right "init=" arg if it exists in the real kernel commandline. For the /proc/1/root, there's no choice but to allow it to be viewed by all users -- though perhaps I can still keep it disabled for chroots.

I'll write up a patch that can handle these two cases and then we'll see where things stand.

-Brad

Hi Alan,

Give this a spin (completely untested): https://grsecurity.net/~spender/systemd2.diff
Remove the previous (systemd.diff) patch before applying this one.

-Brad

Okay problems I ran into (using the grsec test patch and your patch):
http://pastebin.com/RbyKS2S3
This ones are definitely related to to your patch:
http://pastebin.com/wfbVaycg
http://pastebin.com/jU5eBF7j

.config file: http://pastebin.com/hpBawE6M