>>> 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@xxxxxxxxxxxxx> -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
