grsecurity forums

I'm in the process of giving a try to systemd.
I know, I know. Once I have to confess, but I have to see it for myself.

Transition guide suggests to replace the good old /etc/mtab to a symlink pointing at /proc/self/mounts.
In my RBAC policy file I have mtab specified as a readable file for swapon, swapoff. Some copy operation also performed on it, so cp also contains mtab.
If I leave /etc/mtab in the policy, I get this warning:
---
Warning: object does not exist in role root, subject /sbin/swapon for the target of the symlink object /etc/mtab specified on line 2112 of /etc/grsec/policy.
---
The policy gets loaded anyways.
If I replace /etc/mtab with /proc/self/mounts, I get this warning instead:
---
Warning: In role root subject /sbin/swapon, pathname "/proc/self/mounts":
A writable and symlinked directory "/proc/self" points to "/proc/27961".
---
The strange thing is, that /proc/self/mounts does not displayed as a symlink, but rather as a regular file. Also the referred file /proc/27961 is not visible, even if I authenticated as RBAC admin.

Are there any suggestions or experiences what is the proper way of dealing with /etc/mtab as a symlink to /proc/self/mounts?

I haven't tested what is the consequence of these warning in real life, because I haven't rebooted the machine, yet. Sooner or later I have to, so it'll turn out...

Thanks:
Dw.

Hi,

Those symlinks are resolved at enable time, so of course /proc/self is pointing to gradm's entry which will not exist after it completes. What you need to do for cases like this (until I implement some runtime expansion of /proc/self) is add a /proc/*/mounts rule.

BTW, as to your report here:
http://permalink.gmane.org/gmane.linux. ... dened/6122

You should reproduce the same problem with the upstream equivalent of GRKERNSEC_PROC as far as this bug is concerned. Here's an article about it: http://www.linux-dev.org/2012/09/hide-p ... her-users/

Since that code is upstreamed, Lennart will be forced to fix his problem

-Brad