grsecurity forums

I've finally gotten around to learning/understanding the grsec RBAC system and I must say, it's pretty amazing.

The one thing I can't figure out though is what's the "best" way to allow access to the gradm command, for access to the admin role.

I understand only root can enable RBAC and that makes sense. What I'm trying to understand is what's the best way to allow system administration tasks.

Is is to:

a) Allow a certain user role (i.e. my standard non-root login) the ability to "su" and then once su'd to root (from a trusted IP address) to allow access to the gradm command?

b) Allow the my user role access to gradm directly, so I can can run gradm -a admin, giving me access to everything and then allowing su etc.

c) Another way?

It seems that the Full System Learning doesn't consider this "problem" and that if you don't expressly do one or the other during learning you can end up with a RBAC system you can enable but then not disable.

I assume this just means you should do whichever works best for you?

Tim

I always log in to root directly. If you assume your non-root account will be compromised, then su'ing to root isn't safe (less so on a grsec box, but very much so on a vanilla machine). It basically widens the trusted area and makes the parent shells targets of injection/manipulation. Force public key authentication as well.

-Brad

So say you have a deployment user account that needs more privileges than the default policy allows and less privs than the admin role. Would you create a role for the deployment user and give it explicit permissions for exactly what it needs to do?

Does it make sense to create roles for deploying and monitoring that need more acces than default but certainly less than admin.


(sorry if this a newb question...just trying to understand "best practices")

Yes, this kind of separation is encouraged.

-Brad