systemd vs CONFIG_GRKERNSEC_PROC

[Dwokfur]

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

[Dwokfur]

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.

[spender]

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

[Dwokfur]

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

[spender]

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

[Dwokfur]

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.

[alan.d]

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.

[spender]

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

Thanks,
-Brad

[alan.d]

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.

[spender]

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

[alan.d]

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.

[alan.d]

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.

[spender]

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

[spender]

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

[alan.d]

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