On Wed, 2008-07-16 at 15:08 +0900, KaiGai Kohei wrote: > >>> 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. I don't see a reason for supporting multiple parents. -- Stephen Smalley National Security Agency -- 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.
