From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <487D9061.1080304@ak.jp.nec.com> Date: Wed, 16 Jul 2008 15:08:33 +0900 From: KaiGai Kohei MIME-Version: 1.0 To: Stephen Smalley CC: jmorris@namei.org, paul.moore@hp.com, jbrindle@tresys.com, selinux@tycho.nsa.gov Subject: Re: [RFC] An idea of thread/child-domain assignment References: <487C7698.60503@ak.jp.nec.com> <1216129084.9348.27.camel@moss-spartans.epoch.ncsc.mil> <487D5A3D.6090801@ak.jp.nec.com> In-Reply-To: <487D5A3D.6090801@ak.jp.nec.com> Content-Type: text/plain; charset=ISO-2022-JP Sender: owner-selinux@tycho.nsa.gov List-Id: selinux@tycho.nsa.gov >>> 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 DOMBY ; > or > TYPEDOMINANCE [,] ; > > 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 -- 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.