Minimal CIL policy requires process class with transition permission

Minimal CIL policy requires process class with transition permission

[bauen1]

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 ?

Kernel: Linux selinux-pr-test5 5.6.0-2-amd64 #1 SMP Debian 5.6.14-1
(2020-05-23) x86_64 GNU/Linux
policycoreutils: 3.0-1

Thanks for your help, bauen1


; vim: syntax=lisp :

;; initial sids these can be mostly removed after selinux 3.1 and linux 5.7
(sid kernel)
(sid any_socket)
(sid devnull)
(sid file)
(sid file_labels)
(sid fs)
(sid icmp_socket)
(sid igmp_packet)
(sid init)
(sid kmod)
(sid netif)
(sid netmsg)
(sid node)
(sid policy)
(sid port)
(sid scmp_packet)
(sid security)
(sid sysctl)
(sid sysctl_dev)
(sid sysctl_fs)
(sid sysctl_kernel)
(sid sysctl_modprobe)
(sid sysctl_net)
(sid sysctl_net_unix)
(sid sysctl_vm)
(sid tcp_socket)
(sid unlabeled)

(sidorder (kernel any_socket devnull file file_labels fs icmp_socket
igmp_packet init kmod netif netmsg node policy port scmp_packet security
sysctl sysctl_dev sysctl_fs sysctl_kernel sysctl_modprobe sysctl_net
sysctl_net_unix sysctl_vm tcp_socket unlabeled))

;; these are requirements for compiling the policy
(user kernel_u)
(role kernel_r)
(type kernel_t)
(sensitivity s0)
(sensitivityorder (s0))
(level low (s0))
(level high (s0))
(levelrange lowhigh (low high))
(userrange kernel_u lowhigh)
(userlevel kernel_u low)
(userrole kernel_u kernel_r)
(roletype kernel_r kernel_t)
(context kernel_context (kernel_u kernel_r kernel_t lowhigh))

;;
(sidcontext kernel kernel_context)
(sidcontext any_socket kernel_context)
(sidcontext devnull kernel_context)
(sidcontext file kernel_context)
(sidcontext file_labels kernel_context)
(sidcontext fs kernel_context)
(sidcontext icmp_socket kernel_context)
(sidcontext igmp_packet kernel_context)
(sidcontext init kernel_context)
(sidcontext kmod kernel_context)
(sidcontext netif kernel_context)
(sidcontext netmsg kernel_context)
(sidcontext node kernel_context)
(sidcontext policy kernel_context)
(sidcontext port kernel_context)
(sidcontext scmp_packet kernel_context)
(sidcontext security kernel_context)
(sidcontext sysctl kernel_context)
(sidcontext sysctl_dev kernel_context)
(sidcontext sysctl_fs kernel_context)
(sidcontext sysctl_kernel kernel_context)
(sidcontext sysctl_modprobe kernel_context)
(sidcontext sysctl_net kernel_context)
(sidcontext sysctl_net_unix kernel_context)
(sidcontext sysctl_vm kernel_context)
(sidcontext tcp_socket kernel_context)
(sidcontext unlabeled kernel_context)

;; this works
;(class process (transition))
;(classorder (unordered process))
;(allow kernel_t self (process (all)))

;; this should work in theory
;; systemd or load_policy will try to load the policy, but the kernel will
;; return "Invalid argument" and log "SELinux: failed to load policy" to
dmesg.
(class file (read))
(classorder (unordered file))
(allow kernel_t self (file (all)))

Re: Minimal CIL policy requires process class with transition permission

[Stephen Smalley]

On Wed, Jun 17, 2020 at 7:10 AM bauen1 <j2468h@googlemail.com> 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).

Re: Minimal CIL policy requires process class with transition permission

[Stephen Smalley]

On Wed, Jun 17, 2020 at 9:24 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Wed, Jun 17, 2020 at 7:10 AM bauen1 <j2468h@googlemail.com> 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

Re: Minimal CIL policy requires process class with transition permission

[Dac Override]

On Wed, Jun 17, 2020 at 3:36 PM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Wed, Jun 17, 2020 at 9:24 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > On Wed, Jun 17, 2020 at 7:10 AM bauen1 <j2468h@googlemail.com> 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.

Re: Minimal CIL policy requires process class with transition permission

[Stephen Smalley]

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.

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

Re: Minimal CIL policy requires process class with transition permission

[Dominick Grift]

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