On Wed, Jun 17, 2020 at 10:12 AM Dac Override <dac.override@xxxxxxxxx> wrote: > Speaking for myself here. I want to be able to clarify as much as > possible, without having to resort to: "this is added because of some > kernel internal", because those aspects distract when you try to learn > how to write a policy from scratch. Things tend to stick better when > you understand their purpose. Yes, it is mostly a legacy of the original tight coupling of kernel classes/permissions to policy and hardcoded assumptions about different default behaviors for processes (subjects) versus objects (which these days are at least mostly configurable via default rules and the like). So we could probably eliminate the hard requirement here on process transition. Just not sure it would yield a very usable system if you loaded such a policy. > The situation is improving though. I don't think we were able to write > a policy by just being aware of this "process transition" internal in > the recent past. The lifting of the classordering make it possible to > start with just "process transition" and then get all the classes and > perms from dmesg as you go without having to be aware of all the > classes and perms needed (let alone any ordering as now you can just > all unorder it) > > Another path in this picture is the ability to omit unused isids, It > just does not help trying to explain "were just adding these sids and > sidcons due to some kernel internals" Now we can just stick to used > sidcons and explain why they are needed. > > So aside from the "process transition" secret sauce, I think the only > other aspect that might be hard to explain are the sidorder and the > need for sidorder. > > But other than the above now writing a policy from scratch is just > easier. Thanks for that. You're welcome. Another thorny spot for new policy writers is likely when/how to use the various fs_use_* rules and when to use genfscon (and at what granularity); script/selinux/mdp at least will auto-generate a sane default set for you based on kernel configuration. And unfortunately we've grown a set of hardcoded logic around specific filesystem types that need to get generalized and turned into policy-driven rules, as per https://github.com/SELinuxProject/selinux-kernel/issues/2.
