selinux September 2008 archive
Main Archive Page > Month Archives  > selinux archives
selinux: Re: [PATCH 3/3] Thread/Child-Domain Assignment (rev.6)

Re: [PATCH 3/3] Thread/Child-Domain Assignment (rev.6)

From: Joshua Brindle <jbrindle_at_nospam>
Date: Mon Sep 15 2008 - 13:44:17 GMT
To: KaiGai Kohei <>

KaiGai Kohei wrote: > Joshua Brindle wrote: >> KaiGai Kohei wrote:
>>> The attached patch for libsepol add suport for a new policy version
>>> Userspace hierarchy checks are reworked in this revision.
>>> - Boundary feature support:
>>> The upcoming kernel has a feature to define boundary relationship
>>> between two users, roles and types. It enables to restrict a bounded
>>> one can never have wider permissions than its bounds one.
>>> Any XXXX_datum_t structure have "u32 bounds" member to indicate its
>>> bounds, and we can handle it with the latest version of policy format
>>> provided by this patch.
>>> - Loading attributes into kernel space:
>>> The upcoming kernel also allows to load entries of attribute.
>>> The attached patch turn off to drop them, when it tries to write
>>> kernel policy with its version is equal or greater than
>>> Any entries of attribute has a property of TYPEDATUM_PROPERTY_ATTRIBUTE.
>>> - Improvement of type_datum format on kernel/modular policy.
>>> The type_datum entry has several its attribute fields like "primary",
>>> "flavor" and "flags", and these are stored within separated fields
>>> on-disk format. This patch enables to pack them into a single field.
>>> Currently four bits are defined, and rest of them are reserved.
>>> #define TYPEDATUM_PROPERTY_ALIAS 0x0004 /* userspace only */
>>> #define TYPEDATUM_PROPERTY_PERMISSIVE 0x0008 /* userspace only */
>>> - Hierarchy checks are reworked
>>> The existing userspace hierarchy checks are reworked for the upcoming
>>> boundary feature. It can handle parent one based on both newer bounds
>>> relationship and existing name-based hierarchy.
>>> In addition, I put a trick to evaluate conditional rules correctly.
>>> The following example shows a confusable case. A_t is the bounds of B_t,
>>> so B_t can never has wider permission than A_t.
>>> Example)
>>> allow B_t X_t : file { read_file_perms };
>>> if (A_can_write_X) {
>>> allow A_t X_t : file { write_file_perms };
>>> } else {
>>> allow A_t X_t : file { read_file_perms };
>>> }
>>> A_t's permissions on X_t is depend on the 'A_can_write_X', however,
>>> a part of them, like 'read', are unconditionally allowed.
>>> If we can find common permission on both of true/false lists, these
>>> are pulled up to unconditional rules.
>>> Thus, B_t's read permission on X_t is not hierarchy violated in the
>>> above example. It also matches the upcoming kernel behavior no need
>>> to say.
>> Was this the latest patch? I can't seem to apply it either to the latest >> git HEAD or to the last svn revision: > > Sorry, my Thunderbird translated any tabs into spaces. > The patch is made based on the latest subversion repository. > Can you apply the attached one correctly? >

Yes it applies. I'm going to have to track down that bug you reported before merging this because it prevents policy compilation. -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to with the words "unsubscribe selinux" without quotes as the message.