Re: Minimal CIL policy requires process class with transition permission

[Dominick Grift <dominick.grift@defensec.nl>]

Stephen Smalley <stephen.smalley.work@gmail.com> writes:

> On Wed, Jun 17, 2020 at 10:12 AM Dac Override <dac.override@gmail.com> 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.

In theory it should, if you have handleunknown set to allow, which is
recommended in the phase.

>
>> 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.

I agree

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift