Re: [RFC & PATCH] inherited type definition.

[KaiGai Kohei <kaigai@kaigai.gr.jp>]

Hi Karl, Thanks for your comments.

 >> Interesting patch and I'm glad to see you use sediff for testing this - it has
 >> proven very valuable to use when doing work on checkpolicy for us as well. My
 >> concern for this (in addition to Steve's comments) is that it isn't general
 >> enough to solve many of the policy language problems that we commonly see. For
 >> example, this doesn't help with types that are derived on a per-role basis. This
 >> is a conceptually similar problem - I want user_ssh_t to be very similar
 >> staff_ssh_t with some differences - but requires some additional features. I am
 >> interested in extending this because right now it is not possible to easily add
 >> roles to binary policies, like the modules, because the per-role types are not
 >> correctly created.

In my understanding, your concern is that child type/domain always inherit
parent's attachments of roles, and this character make it hard to define
similar type/domain which belong to different roles.

It can be resolved by multi-layer type/domain inheritance.

e.g)
type generic_ssh_t;
type user_ssh_t extends generic_ssh_t;
type staff_ssh_t extends generic_ssh_t;

generic_ssh_t is attached some generic and necessary permissions and attributes,
but generic_ssh_t does not belong to any roles.
user_ssh_t and staff_ssh_t is defined as a child type of generic_ssh_t.
Those are attached specific permissions and attributes, and each type belong to
own roles.

This look like the usage of ATTRIBUTE. But we can't define multi-layer structure
for attribute on current checkpolicy. My extension make it possible.

 >> I don't have a concrete suggestion, but an example would be a policy syntax that
 >> could duplicate the ssh_domain macro. Instead of creating a type based on
 >> another type, it would be creating a type based on a 'type template'. This would
 >> allow creating user_ssh_t and staff_ssh_t, for example, with similar access in
 >> many cases, but also differences (e.g., user_home_ssh_t and staff_home_ssh_t or
 >> a different transition from ssh_exec_t).

Indeed, we can also define such types by 'type template' macros, I think.
But I wonder whether type configuration by multiple macros is enough easy
for general end-user or not.
My original motivation willing to implement TYPE ... EXTENDS is that
making it easier to define original type/domain by using an existing
correct type/domain definition, because defining a new type/domain from
scratch is required so wide knowledge for application, kernel, SELinux and macros.
(Education often requires massive cost.)
In many case, an imitation of existing type/domain is easier than
to enforce end-user learning about application, kernel, SELinux and macros.

Thanks.
-- 
DO NOTHING IS THE WORST POLICY.
KaiGai Kohei <kaigai@kaigai.gr.jp>

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.