Re: [PATCH] unalias of ACL_SELECT_FOR_UPDATE

Gregory Stark wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>
>> Greg Stark <stark(at)enterprisedb(dot)com> writes:
>>> I think we're talking at cross purposes here. I think Kai Gai's
>>> descriptions make sense if you start with a different set of
>>> assumptions. The idea behind SELinux is that each individual object is
>>> access controlled and each user has credentials which grant access to
>>> specific operations on specific objects. As I understand it part of
>>> the goal is to eliminate situations where "setuid" or other forms of
>>> privilege escalation is required.
>> Well, if so, the idea is a miserable failure. SELinux has just as many
>> setuid programs as any other Unix, and absolutely zero hope of removing
>> them. I am not going to take the idea of "remove setuid" seriously when
>> they haven't been able to accomplish it anywhere else.
>
> But can you remove privileges from users to make these programs ineffective?
> So even if you obtain root privileges you're missing the SE privilege which
> the program expects to use?

It is also too radical goal for SELinux. :-)

SELinux intends to prevent "unexpected" privilege escalation, but it does
not mean to eliminate setuids. The "unexpected" means the actions are not
explicitly allowed in the security policy.

The SELinux privileges mechanism works orthogonally with DAC mechanism.
If a user runs a root-setuid program, he can get full-controllable privileges
in the DAC rules, but SELinux checks his privileges from different aspect to
mask unallowed privilges due to the MAC rules.
Thus, SELinux makes its decision based on only security contexts, independent
from user identifier and other factors.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>