grsecurity forums

Changing topic, was: "RBAC does not handle hardlink-rename."

RBAC seems to fail hard if the subject's binary is replaced with binary from the same filesystem, if the subject's binary is already running. If the 'mv' is from different filesystem or the binary is not running, there's not a problem.
The problem is trigged after reloading policy, after the `mv`.
---

Hi.

It seems that RBAC does not handle rename of hardlink, keeping old path in memory as the path of given inode.

For example, if I have subject rule for /usr/sbin/metalog and run prelink, I will start getting:

Code: Select all

[2330407.753718] grsec: (root:U:/) use of CAP_SYSLOG denied for /usr/sbin/metalog.#prelink#.lh9QyW[metalog:1033] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/metalog.#prelink#.lh9QyW[metalog:1032] uid/euid:0/0 gid/egid:0/0
[2330407.753739] grsec: (root:U:/) use of CAP_SYSLOG denied for /usr/sbin/metalog.#prelink#.lh9QyW[metalog:1033] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/metalog.#prelink#.lh9QyW[metalog:1032] uid/euid:0/0 gid/egid:0/0
[2330407.753742] grsec: (root:U:/) use of CAP_SYSLOG denied for /usr/sbin/metalog.#prelink#.lh9QyW[metalog:1033] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/metalog.#prelink#.lh9QyW[metalog:1032] uid/euid:0/0 gid/egid:0/0

Same goes for Gentoo's Portage. If $PORTAGE_TMPDIR (default /var/tmp/portage) is on the same filesystem as rootfs, it will try to hardlink instead of copy the files from $D (install path after building) to target path. Then it will start think that /usr/bin/WHATEVER that is already running is indeed from /var/tmp/portage/cat/app/image/usr/bin/WHATEVER and as there's no subject for that, it will deny the accesses (reducing the role to user:U:/).

After prelink and un-prelink everything was fine until `gradm -R` after loading new policy (the only changes were for git subject, totally unrelated). Disabling RBAC via `gradm -D` and re-enabling it with `gradm -E` does not fixes the issue. The only workaround is to restart the given binary like in my case, restart all services.

Bump.

Eventually I had to reboot the box and even than, in shutdown role, /sbin/init was stopped by the RBACxHARDLINK maddness that prelink left behind (I have iLO access there) so I could see at least it. That's pretty serious issue, that was unnoticalbe until I did gradm -R.

Gentoo's method of updating binaries is a known issue with RBAC -- the problem is that in RBAC there can only be one permission granted for a given active inode. It can handle renames fine, but when you hardlink a file, then rename/replace the original file, the only file that will have the permission of the original is the still-existing hardlink. Removal of all hardlinks to a particular file is required to activate RBAC's policy recreation on an object.

Other Gentoo users have modified portage so that it always updates as if the files are on different partitions to avoid this problem.

-Brad

The issue is not limited to gentoo, as you can see I had the issue with `prelink` that even redhat uses in its enterprise linux releases..

Would you kindly comment whatever hardlink magic that portage and prelink does will be supported at some point?

For future reference, as one already done `prelink` or anything else that does hardlink-magic on a host, how should one proceed? Something like:

Code: Select all

cp -a /sbin/init /sbin/init.new
mv /sbin/init.new /sbin/init

will do the trick? Will it force policy recreation? Presuming that it won't ever get support on RBAC level, it would be nice to have any way to recover or 'fixing' it before gradm -R break running system apart.

*Friendly bump*

Knowing how to force policy recreation would be good as for example if I have a perl as a symlink, it happend few times to me that after system upgrade I had to reload rbac to be able to use perl again.

Something is insanly wrong with RBAC.

What I did was

Code: Select all

cd /usr/sbin
cp -a metalog metalog.new && mv metalog.new metalog

then reloaded rbac with 'gradm -R' and what I got was:

[1696864.543014] grsec: (root:U:/) denied access to hidden file /var/log/everything by /usr/sbin/metalog.new[metalog:1023] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/metalog.new[metalog:1022] uid/euid:0/0 gid/egid:0/0

I didn't even used hardlinks and RBAC have no idea what just happend!

@Spender, please, be so kind and take a look at this very thing.

Steps to reproduce with metalog as an example:

sugoi [SSH] sbin # cp -a metalog metalog.new
‘metalog’ -> ‘metalog.new’
sugoi [SSH] sbin # mv metalog.new metalog
mv: overwrite ‘metalog’? y
‘metalog.new’ -> ‘metalog’
sugoi [SSH] sbin # gradm -R
Password:
sugoi [SSH] sbin # logger foo
sugoi [SSH] sbin # dmesg |grep metalog
[1697631.725927] grsec: From xx.xx.xx.xx: (root:U:/) use of CAP_SYSLOG denied for /usr/sbin/metalog.new[metalog:5792] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/metalog.new[metalog:5791] uid/euid:0/0 gid/egid:0/0
[1697631.725932] grsec: From xx.xx.xx.xx: (root:U:/) use of CAP_SYSLOG denied for /usr/sbin/metalog.new[metalog:5792] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/metalog.new[metalog:5791] uid/euid:0/0 gid/egid:0/0
[1697631.725936] grsec: From xx.xx.xx.xx: (root:U:/) use of CAP_SYSLOG denied for /usr/sbin/metalog.new[metalog:5792] uid/euid:0/0 gid/egid:0/0, parent /usr/sbin/metalog.new[metalog:5791] uid/euid:0/0 gid/egid:0/0
sugoi [SSH] sbin #

I've tried if I can double `cp -a` it, but it fails hard:

Code: Select all

sugoi [SSH] sbin # cp -a metalog metalog.new
‘metalog’ -> ‘metalog.new’
sugoi [SSH] sbin # cp -a metalog.new metalog
cp: overwrite ‘metalog’? y
‘metalog.new’ -> ‘metalog’
cp: cannot create regular file ‘metalog’: Text file busy
sugoi [1] [SSH] sbin #

Yet another edit: if I add -f to cp, it actually can replace the metalog file with metalog.new and after reload, everything is all right.
Edit: Updated thread title and first post.
Edit: fwiw thats on grsecurity-3.0-3.15.10-201408140023.patch

Downgraded to 3.14.5 (not sure which grsec version, I just used old bzImage, no sources laying around) and I can confirm that 3.14 DOES NOT have this issue, meaning this is a new bug in 3.15.

Ask upstream why they changed the user-visible behavior of renames on running binaries in 3.15. This is why it's breaking.

Before 3.15:

run /root/testbin (app that just sleeps)
cp /root/testbin /root/testbin.new
mv /root/testbin.new /root/testbin
ls -al /proc/`pidof testbin`/exe

it will show /root/testbin (deleted) -> this is the correct answer as the contents of the running binary are those pertaining to the original /root/testbin that was clobbered by the rename

After 3.15:

run /root/testbin (app that just sleeps)
cp /root/testbin /root/testbin.new
mv /root/testbin.new /root/testbin
ls -al /proc/`pidof testbin`/exe

it will show /root/testbin.new (deleted) -> this is wrong. The running process has nothing to do with whatever file replaced it.

-Brad

Do you plan to adjust RBAC to preserve working state as in pre-3.15 kernels?

Meanwhile I will ask on lkml about that.

for reference: https://lkml.org/lkml/2014/9/6/120

The rename issue has been fixed by grsecurity for 3.16 kernel. Thank you Spender, I will poke upstream anyway to do the same.