On Sat, Jun 13, 2020 at 9:44 AM Mikhail Novosyolov <m.novosyolov@xxxxxxxxxxxx> 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.
