Re: [RFC] An idea of thread/child-domain assignment

[KaiGai Kohei <kaigai@ak.jp.nec.com>]

>>> In other words, this idea requires to change our viewpoint for child domain.
>>> Previously, these are mutually independent domain, but a child domain will
>>> mean a state with restricted operations compared to its parent domain.
>> I tend to agree that we should support such changes in the kernel
>> mechanism and let the use of it be determined by the policy.
>>
>> In terms of hierarchy though, the plan was to replace the current
>> name-based hierarchy with an explicitly declared hierarchy.
> 
> It needs a new policy statement like:
> 
>   TYPE <child domain> DOMBY <parent domain>;
>     or
>   TYPEDOMINANCE <parent domain> <child domain> [,<child domain>] ;
> 
> I guess these relationships are represented as a ebitmap structure
> in the kernel, and used to mask permissions during AVC entry creation.

Should it be possible to have multiple parent domains on the explicitly
declared hierarchy?

The current name-based hierarchy only supports tree-shaped structure.
(A child domain can have one parent at most.)
It implicitly enables to avoid a matter of loop of relationship between
parents and children.

If we can define a domain with multiple parent, it makes the logic to
detect the loop complicated.

-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>

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