At work I'm used to tools like eTrust Access Control (aka SEOS). eTrust takes away the ability to manage the eTrust config from root and puts it in the hands of "security admin". So there's a good separation of duties; security admin control the security ruleset, but are limited by the OS permissions (so even if they granted themselves permission to modify /etc/shadow, the standard OS permissions would block them) and system admins control the OS (so they can be root, but can't override eTrust).
Ideally this type of separation would be useful in the SELinux world as well. OK, maybe this is a bit of an overkill for my own machines, but then I do have bastion hosts and internal segmented networking at home; I do overkill at times :-)
The problem is that I can't see how to prevent this. There are too many access points (not just the CLI tools but the pp files and the /sys tree and I don't know what else).
I do note that /etc/selinux has selinux_config_t and /sys/fs/selinux has security_t so maybe a policy that deny's everyone except a new security_admin_t permission to modify those files might work?
Has anyone actually attempted this?
On 01/23/2015 06:01 PM, Stephen Harris wrote:
At work I'm used to tools like eTrust Access Control (aka SEOS). eTrust takes away the ability to manage the eTrust config from root and puts it in the hands of "security admin". So there's a good separation of duties; security admin control the security ruleset, but are limited by the OS permissions (so even if they granted themselves permission to modify /etc/shadow, the standard OS permissions would block them) and system admins control the OS (so they can be root, but can't override eTrust).
Ideally this type of separation would be useful in the SELinux world as well. OK, maybe this is a bit of an overkill for my own machines, but then I do have bastion hosts and internal segmented networking at home; I do overkill at times :-)
The problem is that I can't see how to prevent this. There are too many access points (not just the CLI tools but the pp files and the /sys tree and I don't know what else).
I do note that /etc/selinux has selinux_config_t and /sys/fs/selinux has security_t so maybe a policy that deny's everyone except a new security_admin_t permission to modify those files might work?
Has anyone actually attempted this?
You would need to disable the unconfined.pp module and the unconfineduser.pp module and run all of your users as confined user including the admin user as sysadm_t.
You could also set the secure_ booleans
getsebool -a | grep secure_* secure_mode --> off secure_mode_insmod --> off secure_mode_policyload --> off
On Mon, Jan 26, 2015 at 03:29:23PM -0500, Daniel J Walsh wrote:
You could also set the secure_ booleans
Is this in addition to or instead of removing unconfined users?
getsebool -a | grep secure_* secure_mode --> off secure_mode_insmod --> off secure_mode_policyload --> off
Without removing unconfined users this definitely stops setenforce working... but root can still set the boolean off.
So playing around, just to see what destruction I can cause...
Window 1 had an unconfined user doing tail -f /var/log/messages Window 2 had a guest_u user Window 3 had a sysadm_u user, su'd to root
In window 3 I did 'semanage -d unconfined' and then 'semanage -d unconfineduser'. At that point that window threw up libsemanage.dbase_llist_query: could not query record value (No such file or directory).
and control-C, control-Z, control-\ all did nothing interesting.
Window 1 (unconfined) displayed tonnes of errors from messages, around things like staff_u not being valid. Then froze, then eventually ssh session died; I'm guessing SELinux starting blocking the port. SELinux: Context staff_u:unconfined_r:samba_unconfined_net_t:s0 became invalid (unmapped). SELinux: Context unconfined_u:system_r:samba_unconfined_net_t:s0-s0:c0.c1023 became invalid (unmapped). SELinux: Context staff_u:system_r:samba_unconfined_net_t:s0 became invalid (unmapped).
The one session that stayed active was the guest_u one... but not a lot I can do, there!
root login on the console failed: Unable to get valid context for root
Cannot make/remove an entry for the specified session [342970.402198] audit: backlog limit exceeded [342970.402622] audit: backlog limit exceeded [342970.402983] audit: backlog limit exceeded
ssh as the sysadm_u user fails with context issues.
I can login with the sysadm_u user on the console, although this user can't see his own home directory.
And that was able to su to root and re-enable the two modules :-)
-
Daniel J Walsh -
Stephen Harris