On Wed, Jun 17, 2020 at 3:36 PM Stephen Smalley <stephen.smalley.work@xxxxxxxxx> wrote: > > On Wed, Jun 17, 2020 at 9:24 AM Stephen Smalley > <stephen.smalley.work@xxxxxxxxx> wrote: > > > > On Wed, Jun 17, 2020 at 7:10 AM bauen1 <j2468h@xxxxxxxxxxxxxx> wrote: > > > > > > Hello, > > > > > > I've recently started playing with CIL and for various reasons I wanted > > > to start with the smallest possible policy. > > > > > > After having some issues with a tiny CIL policy that compiles but does > > > not actually load, I tracked it down to a hard requirement (of the > > > kernel ?) on the permission `transition` of the `process` class. > > > Is there a reason for this or is this a bug ? > > > > Yes, the kernel security server depends on at least this class and > > permission being defined in policy for some of its internal logic; > > otherwise you will get some rather odd behavior. I suppose we could > > make the kernel handle it more gracefully, or change libsepol to catch > > this and flag it as an error when writing a policy with the target > > platform set to Linux (it wouldn't be an error when writing a Xen > > policy, for example). > > By the way, there is a program in the kernel source tree, under > scripts/selinux/mdp, that will generate a fairly minimalist policy for > that kernel with all of its classes/permissions defined, a single > user/role/type, fs_use and genfscon rules for all filesystem types > configured, and allow rules allowing everything. See > Documentation/admin-guide/LSM/SELinux.rst. That however generates > policy.conf not CIL currently although adding support for generating > CIL is an open issue in GitHub, > https://github.com/SELinuxProject/selinux-kernel/issues/45 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. 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.
