CentOS - Jan 2015 - How to prevent root from managing/disabling SELinux

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?

-- 

rgds
Stephen

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 :-)

-- 

rgds
Stephen