Re: [RFC & PATCH] inherited type definition.

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

Hello, Thanks for your comments.

> 1) Should the child domain inherit all rules that involved the parent
> domain at all, or only rules where the parent domain was the
> source/subject in the rule?  It looks like you have chosen the former,
> but this means that any domain that can act on the parent domain can act
> in the same manner on the child domain directly; not clear that this is
> always what you want.

In my patch, child domain/type inherit all rules including target/object
and area of ROLE clearly, not only source/subject.
(Those source/target is also included in TYPE_TRANSITION statements.)
Any permissions to parent means permissions to child/descendant concurrently.


> 2) Should the child domain inherit rules between the parent and the
> child, i.e. should the child be able to do anything to itself that the
> parent can do to it?  It looks like you are inheriting such rules, but
> is this always desirable, e.g. the parent may need permissions to set up
> the child, control it, kill it, etc that the child may not need to
> itself.

When parent has permissions to himself, child also has permissions to his
parent and himself(child). In my patch, to inherit type/domain always expand
descendant's permissions. I intend to define a child type/domain which has
tiny larger permission than own parent low cost.

I think definition of reductive permission child-type/domain is the next
action assignment. If child does not need a part of the parent's permissions,
those should be revoked by DENY statement for example.


> 3) What should happen with rules between the parent and itself?  It
> looks like you are translating "self" rules to only involve the child
> and its descendants, but this would still mean that any explicit rule of
> the form "allow parent_t parent_t:process sigkill;" would be inherited
> by the child, i.e. "allow child_t parent_t:process sigkill;", right?

It's a bit wrong.
When child_t inherit parent_t, "allow parent_t parent_t:process sigkill;"
is unrolled to "allow {parent_t child_t} {parent_t child_t}:process sigkill;"
The number of conbination is 4.

"allow parent_t self:process sigkill;" is unrolled as follows:
  "allow parent_t parent_t:process sigkill;"
  "allow parent_t child_t:process  sigkill;"
  "allow child_t  child_t:process  sigkill;"

child_t is dealt as self-domain from parent_t's viewpoint.
But parent_t is not dealed as self-domain from child_t's viewpoint,
because child_t has divaricated from parent_t yet.

This is my opinion, others may have different aspect to 'self'.
We should collect up how to deal 'self' on type-inheritance-tree, I think.


> 4) What should happen with transition rules that involve the parent?  In
> some cases, you will likely want to inherit them, but in others, you may
> want the child to transition to a separate derived domain from the one
> used by the parent.

parent_t/child_t shares same transition rule for same exec type.
Maybe, any kind of overriding semantics is necessary.

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.