13.06.2020 23:08, Stephen Smalley пишет: > 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. 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.
