grsecurity forums

When I remount root filesystem to read-only, while gradm is running, suddenly the RBAC rules affecting symlinks stop working

An example for illustration:

On my system (Debian), /bin/sh is a symlink to /bin/dash. In my policy, I only have rules for the target (/bin/dash) and not for the symlink (/bin/sh). This is the way the learning process generates the rules.

suppose this is my subject for /bin/bash:

subject /bin/bash o {
...
/bin/dash x
...
}

steps to reproduce:
1. log in bash terminal
2. start RBAC (gradm -E)
3. start /bin/sh - everything works now
4. remount root to read-only (mount -o remount,ro /)
5. start sh again (/bin/sh) - /bin/sh no such file or directory
and in my logs, I see: grsec: denied access to hidden file /bin/sh by /bin/bash
6. repeat step 5 (/bin/sh) - now all works again

--- END OF EXAMPLE ---

same problem is with the symlinks to .so libraries in /lib/x86_64-linux-gnu/ and /usr/lib/x86_64-linux-gnu/

I am using gradm v3.0

I'm not sure why it would affect symlinks specifically -- what filesystem are you using? Mounting or remounting in general however isn't (currently) supported while RBAC is enabled, since we don't modify the actual data of the drives at all.

-Brad

I am using ext4 filesystem.

Could you please clarify what you mean by "since we don't modify the actual data of the drives at all" ?

Also, I have tried authenticating as admin and then remounting to read-only and I have same problem as described above.

I can see now that this will be quite a problem for me. My root filesystem is normally mounted read-only (/home, /tmp and /var being on separate read-write partitions). If I need to modify a file or install a package, I need to remount to read-write and after back to read-only. (apt-get has hooks which do this automatically). But now it looks as if I will need to disable RBAC each time I need to modify a file on my root partition.

Speaking of symlinks, what is the recommended policy. When /bin/sh is a symlink to /bin/dash, normally, should I need to allow both, or is /bin/dash enough ?

The symlink needs to at least have 'find' permission, but you will also need permission to the target of the symlink. Generally, the symlink should have the same permissions as the target. Regarding not modifying data on the drives, unlike systems like SELinux that depend on modifying extended attributes on the filesystem to place policy, our RBAC stores all the policy in one central location without having to modify the rest of the filesystem.

The reason for the symlink not working after the remount may be because you didn't have an explicit rule for the /bin/sh symlink itself in the policy for /bin/bash, causing the lookup to fall back on a lookup for /, which now had a different ino/dev after the remount.

-Brad

how can the ino/dev be different after the remount?
Are we talking about inode number and device number ? i.e:

stat -c'%d %i' /bin/sh

These don't change after remounts

Before you do the remount, are you able to run /bin/sh twice?

-Brad

yes, before the remount, I can run /bin/sh as many times as I want

After the remount, it does not work the first time, but works thereafter (as described before)