How to off RBAC in SELinux?

How to off RBAC in SELinux?

[Mikhail Novosyolov]

Hello,

Is it possible to remove any checks for RBAC (role-based access control) violations and check only against MLS/MCS rules?

What I have:
1) a system with most files labelled correctly according to a Fedora-based SELinux policy, which in turn is based on the refpolicy;
they will probably have to be kept to make what I want work
2) RBAC-based control from SELinux is not needed, e.g. it is not needed to prevent httpd from executing 3rd party binaries
3) MLS is needed, e.g. it is needed to verify that httpd cannot access "secret" documents

If I understood correctly, main calculations are done in context_struct_compute_av() (security/selinux/ss/services.c), but it does not query MLS separately.
Also, all actions are prohibited by default, the problem is that the policy specifies what to allow, but I would like to wise-a-versa specify what to deny, but keep MLS parts working as is.

The question is: is it possible to make selinux ignore (2), either in the kernel or in policy?

In other words, how to make SELinux make allow-or-deny decisions based on MLS/MCS only, without RBAC?
The only question that must be answered is: does this action violate rules of accessing objects of different level of secrecy (sN:cM) or not.

Please give a clue where to start looking for a solution. Thanks!

Re: How to off RBAC in SELinux?

[Stephen Smalley]

On Fri, Jun 12, 2020 at 4:05 PM Mikhail Novosyolov
<m.novosyolov@rosalinux.ru> wrote:
>
> Hello,
>
> Is it possible to remove any checks for RBAC (role-based access control) violations and check only against MLS/MCS rules?
>
> What I have:
> 1) a system with most files labelled correctly according to a Fedora-based SELinux policy, which in turn is based on the refpolicy;
> they will probably have to be kept to make what I want work
> 2) RBAC-based control from SELinux is not needed, e.g. it is not needed to prevent httpd from executing 3rd party binaries
> 3) MLS is needed, e.g. it is needed to verify that httpd cannot access "secret" documents
>
> If I understood correctly, main calculations are done in context_struct_compute_av() (security/selinux/ss/services.c), but it does not query MLS separately.
> Also, all actions are prohibited by default, the problem is that the policy specifies what to allow, but I would like to wise-a-versa specify what to deny, but keep MLS parts working as is.
>
> The question is: is it possible to make selinux ignore (2), either in the kernel or in policy?
>
> In other words, how to make SELinux make allow-or-deny decisions based on MLS/MCS only, without RBAC?
> The only question that must be answered is: does this action violate rules of accessing objects of different level of secrecy (sN:cM) or not.
>
> Please give a clue where to start looking for a solution. Thanks!

The problem you would quickly run into is that you always need
exceptions in any MLS policy, e.g. files that need to be readable
and/or writable in violation of the normal MLS restrictions and
processes that need to be exempted from them.  The way you do that in
SELinux is to use different TE types and domains and provide OR
clauses in the MLS constraints to exempt them.  So I doubt you truly
want to disable RBAC/TE altogether.  What you could do is to reduce
the policy to just the minimal set of domains and types needed to
support those distinctions and leave most things labeled with the same
domain/type.

If using refpolicy, you want to build with TYPE=mls rather than mcs if
you truly want MLS-style enforcement.  MCS in contrast is opt-in and
only applied to specific domains/types, not to most processes.  In
Fedora/RHEL, you want the -mls policy rather than the default targeted
policy.

Alternatively, you could create your own policy from scratch rather
than using refpolicy.  scripts/selinux/mdp will generate a relatively
minimalist policy for your kernel but then it is up to you to turn it
into something real.  You'd need to modify the stub MLS constraints it
generates, either replacing them with those from refpolicy or writing
your own.

And then there is the option of using another security module or
rolling your own if none of the above works for you.

Re: How to off RBAC in SELinux?

[Mikhail Novosyolov]

12.06.2020 23:44, Stephen Smalley пишет:
> On Fri, Jun 12, 2020 at 4:05 PM Mikhail Novosyolov
> <m.novosyolov@rosalinux.ru> wrote:
>>
>> Hello,
>>
>> Is it possible to remove any checks for RBAC (role-based access control) violations and check only against MLS/MCS rules?
>>
>> What I have:
>> 1) a system with most files labelled correctly according to a Fedora-based SELinux policy, which in turn is based on the refpolicy;
>> they will probably have to be kept to make what I want work
>> 2) RBAC-based control from SELinux is not needed, e.g. it is not needed to prevent httpd from executing 3rd party binaries
>> 3) MLS is needed, e.g. it is needed to verify that httpd cannot access "secret" documents
>>
>> If I understood correctly, main calculations are done in context_struct_compute_av() (security/selinux/ss/services.c), but it does not query MLS separately.
>> Also, all actions are prohibited by default, the problem is that the policy specifies what to allow, but I would like to wise-a-versa specify what to deny, but keep MLS parts working as is.
>>
>> The question is: is it possible to make selinux ignore (2), either in the kernel or in policy?
>>
>> In other words, how to make SELinux make allow-or-deny decisions based on MLS/MCS only, without RBAC?
>> The only question that must be answered is: does this action violate rules of accessing objects of different level of secrecy (sN:cM) or not.
>>
>> Please give a clue where to start looking for a solution. Thanks!
>
> The problem you would quickly run into is that you always need
> exceptions in any MLS policy, e.g. files that need to be readable
> and/or writable in violation of the normal MLS restrictions and
> processes that need to be exempted from them.  The way you do that in
> SELinux is to use different TE types and domains and provide OR
> clauses in the MLS constraints to exempt them.  So I doubt you truly
> want to disable RBAC/TE altogether.

I am aware of this and that is why I want to keep existing types,
domains and labels and not break those exceptions. What I want to
change is make the kernel not dissallow access when RBAC/TE is violated,
unless MLS rules are violated.

> What you could do is to reduce
> the policy to just the minimal set of domains and types needed to
> support those distinctions and leave most things labeled with the same
> domain/type.

It would require reworking the whole policy and rewriting MLS exceptions...
It is very near to writing a policy from scratch, I think.

Patching the kernel to achieve this will be OK, but, after studying the code,
it seems that the whole selinux was first designed to block access
when RBAC/TE rules are violated, and then MLS was added there... So it is not
obvious which part of the code would better be changed to achieve this aim,
and how hard it will be to achieve it.

Re: How to off RBAC in SELinux?

[Stephen Smalley]

On Sat, Jun 13, 2020 at 9:44 AM Mikhail Novosyolov
<m.novosyolov@rosalinux.ru> wrote:
> I am aware of this and that is why I want to keep existing types,
> domains and labels and not break those exceptions. What I want to
> change is make the kernel not dissallow access when RBAC/TE is violated,
> unless MLS rules are violated.
>
> > What you could do is to reduce
> > the policy to just the minimal set of domains and types needed to
> > support those distinctions and leave most things labeled with the same
> > domain/type.
>
> It would require reworking the whole policy and rewriting MLS exceptions...
> It is very near to writing a policy from scratch, I think.
>
> Patching the kernel to achieve this will be OK, but, after studying the code,
> it seems that the whole selinux was first designed to block access
> when RBAC/TE rules are violated, and then MLS was added there... So it is not
> obvious which part of the code would better be changed to achieve this aim,
> and how hard it will be to achieve it.

IMHO that's not a good plan.  Consider for example what happens if you
allow a domain to override MLS constraints (ala mlstrustedsubject) and
you don't enforce TE at all.  Then what prevents a untrusted process
running at the same level from ptrace'ing that trusted domain in order
to bypass MLS, or overwriting its exec type with arbitrary code, or
any number of other things that could be used to subvert it.  That
only works if you are willing to rely entirely on DAC separation for
that kind of protection.  That's more along the lines of Smack's
model.

From an implementation point of view, it would be easy enough to
modify context_struct_compute_av() to just initialize the allowed
access vector to all-ones instead of zero, drop the nested ebitmap
loop for computing over the TE rules, and then walk the constraints
(which include the MLS constraints as a subset) to remove any
permissions that violate the MLS restrictions.  Essentially
context_struct_compute_av() reduces to just the constraint logic in
your scenario and the rest of the function can go away.  But that
leaves you open to the problem noted above.  At that point you might
as well just use Smack if that does what you need.  But understand
then that you are relying on capabilities and DAC as external
dependencies, so correct configuration and use of those is crucial and
not something under Smack's control.

Re: How to off RBAC in SELinux?

[Mikhail Novosyolov]

13.06.2020 23:08, Stephen Smalley пишет:
> On Sat, Jun 13, 2020 at 9:44 AM Mikhail Novosyolov
> <m.novosyolov@rosalinux.ru> wrote:
>> I am aware of this and that is why I want to keep existing types,
>> domains and labels and not break those exceptions. What I want to
>> change is make the kernel not dissallow access when RBAC/TE is violated,
>> unless MLS rules are violated.
>>
>>> What you could do is to reduce
>>> the policy to just the minimal set of domains and types needed to
>>> support those distinctions and leave most things labeled with the same
>>> domain/type.
>> It would require reworking the whole policy and rewriting MLS exceptions...
>> It is very near to writing a policy from scratch, I think.
>>
>> Patching the kernel to achieve this will be OK, but, after studying the code,
>> it seems that the whole selinux was first designed to block access
>> when RBAC/TE rules are violated, and then MLS was added there... So it is not
>> obvious which part of the code would better be changed to achieve this aim,
>> and how hard it will be to achieve it.
> IMHO that's not a good plan.  Consider for example what happens if you
> allow a domain to override MLS constraints (ala mlstrustedsubject) and
> you don't enforce TE at all.  Then what prevents a untrusted process
> running at the same level from ptrace'ing that trusted domain in order
> to bypass MLS, or overwriting its exec type with arbitrary code, or
> any number of other things that could be used to subvert it.  That
> only works if you are willing to rely entirely on DAC separation for
> that kind of protection.  That's more along the lines of Smack's
> model.
Thanks for explaining, now I have understood what you mean. Sounds reasonable.
> From an implementation point of view, it would be easy enough to
> modify context_struct_compute_av() to just initialize the allowed
> access vector to all-ones instead of zero, drop the nested ebitmap
> loop for computing over the TE rules, and then walk the constraints
> (which include the MLS constraints as a subset) to remove any
> permissions that violate the MLS restrictions.  Essentially
> context_struct_compute_av() reduces to just the constraint logic in
> your scenario and the rest of the function can go away.  But that
> leaves you open to the problem noted above.  At that point you might
> as well just use Smack if that does what you need.  But understand
> then that you are relying on capabilities and DAC as external
> dependencies, so correct configuration and use of those is crucial and
> not something under Smack's control.