grsecurity forums

Hi there,

I've been slowly familiarizing myself with grsecurity's RBAC but I'm hitting a few "strategy" roadblocks. Hopefully someone will shed light on those (they might be noob questions or already answered ones - I'm sorry if that's the case, I didn't find anything relevant on the forum). The test environment is running centos7, but the questions should be relevant to other distros with package management and systemd.
Note: the policy was fully learned *after* boot in order to have a stricter/smaller policy.

Q1- managing services (ie. stop/start) with systemctl:
As role admin (gradm -a admin), systemctl start/stop commands will trigger policy denies. The reason is that systemctl connects to systemd, which is running under the root role. Since the policy was learned after boot, we don't have any rules for starting/stopping services as root, hence the denies.

Some workarounds could be:
a- learn a full policy with starting/stopping the services
b- same as above, but instead of adding specific acls to each daemon, use inheritance and give the bulk of permissions to systemd
c- temporarily disable the RBAC system, start/stop services, and re-enable it.
d- find a way (= patch grsecurity) to have temporary role inheritance for systemd when systemctl connects to it from the admin role. But that doesn't sound like an easy thing to do and is maybe not more secure than a- or b-.

Q2- updating the system packages (in that case, with yum):
As yum can update the whole system and start/stop services:
a- either it needs to be run as the admin role (provided a workaround for Q1- is found). Con: in an environment with many servers, it is inconvenient to log into each server as the admin role in order to do a "yum update"
b- or if run from cron, yum (or crond, if the policy has inheritance) has to have a very permissive policy set, ie. almost no restrictions at all. It kinds of defeat the purpose of the RBAC system to have a single command running as root being able to modify the whole system. That could be mitigated by running it with a different role transitionning from crond, but I don't see any way to do that without needing a typed password without going back to square one.

Maybe another way would be to have a central trusted server issuing yum update commands via ssh, with a dedicated role.

So - what is the strategy recommended by fellow users for 1- and 2- ?

Thanks !

PS: kudos to the grsecurity team. I just wished more people in the linux world would be security-conscious.

Hi Ivan,

You'll probably need to wait until systemd starts using kdbus before I can do anything about that problem. Since we don't require any userland changes, it would be too difficult to track how systemd caused the change in a different process.

-Brad

Hi Brad,

Thanks for the lighting fast answer. It looks like you're favoring some kind of inheritance, as I was thinking in Q1/-d...

Until there's an alternative, I'm wondering what you would recommend - would it be too much to ask which option you would choose for Q1/Q2 ? (I know time is scarce, no explanations needed). The number of users updating to systemd distros will defintely grow, so having your expert opinion will really help.

Thanks again !
Ivan