2017-01-16 15:05:53

by zhuxian

[permalink] [raw]
Subject: [refpolicy] Why root is allowed to set the selinux to permissive mode?

Hi,
Why root is allowed to set the selinux to permissive mode?
If a process running with root account, and it has been compromised and the attacker get the root permission, then it can set selinux to permissive mode and do anything it want.
I think one of the main purpose of SELinux is to restrict the root account's permission. But as discussed above, the root account can bypass all policy just by setting the permissive mode.

I check the refpolicy and get the following:
# semanage login -l
Login Name SELinux User
...
root root
...

#semanage user -l
SELinux User SELinux Roles
root staff_r sysadm_r
...

# seinfo --role=sysadm_r -x|grep sysadm_t
sysadm_t

# sesearch -t security_t -c security -p setenforce --allow
Found 3 semantic av rules:
allow sysadm_t security_t : security { setenforce setbool } ;
allow selinux_unconfined_type security_t : security { load_policy setenforce setbool } ;
allow secadm_t security_t : security { setenforce setbool } ;
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20170116/f1876f10/attachment.html


2017-01-16 15:40:33

by Dac Override

[permalink] [raw]
Subject: [refpolicy] Why root is allowed to set the selinux to permissive mode?

On 01/16/2017 04:05 PM, Zhuxian (Kurt) via refpolicy wrote:
> Hi,
> Why root is allowed to set the selinux to permissive mode?

It's probably not what you mean, but I do not like it either that
sysadm_t is (directly) associated with "security setenforce" (and others
like setbool) for a reason that is in a sense similar to your reason
(the principle of least privilege)

The reason is probably: it is a compromise, a trade-off between
efficiency and effectiveness.

But, yes I agree with you, this is a bummer because selinuxfs should not
be messed with manually anyway and so from that perspective there is no
need to associate this permission with sysadm_t. Instead of could just
confine setenforce, setsebool, load_policy.

Expensive, sure, but at least consistent with the principle of least
privilege.

> If a process running with root account, and it has been compromised and the attacker get the root permission, then it can set selinux to permissive mode and do anything it want.
> I think one of the main purpose of SELinux is to restrict the root account's permission. But as discussed above, the root account can bypass all policy just by setting the permissive mode.
>
> I check the refpolicy and get the following:
> # semanage login -l
> Login Name SELinux User
> ...
> root root
> ...
>
> #semanage user -l
> SELinux User SELinux Roles
> root staff_r sysadm_r
> ...
>
> # seinfo --role=sysadm_r -x|grep sysadm_t
> sysadm_t
>
> # sesearch -t security_t -c security -p setenforce --allow
> Found 3 semantic av rules:
> allow sysadm_t security_t : security { setenforce setbool } ;
> allow selinux_unconfined_type security_t : security { load_policy setenforce setbool } ;
> allow secadm_t security_t : security { setenforce setbool } ;
>
>
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>


--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 648 bytes
Desc: OpenPGP digital signature
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20170116/24c95da3/attachment.bin