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

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

Joshua Brindle wrote:
> KaiGai Kohei wrote:
>> Joshua Brindle wrote:
>>> KaiGai Kohei wrote:
>>>> The following patch is revised one for libsepol.
>>>>
>>>> Updates:
>>>>  - The properties of type_datum are packed within the third word of
>>>>    type entries in the kernel policy.
>>>>    The first bit (TYPEDATUM_PROPERTY_PRIMARY) means the entry is a
>>>>    primary type, and the second bit (TYPEDATUM_PROPERTY_ATTRIBUTE)
>>>>    means the entry is an attribute.
>>>>
>>> I didn't see an answer in the current threads, and this looks like
>>  > the latest userland patch series so I'll ask here: What is
>> the purpose  > of the properties? We can infer what it knows
>> from the other fields
>>> in the datum, right?
>> Stephen said as follows:
>> http://marc.info/?l=selinux&m=121882413424973&w=2
>>
>>> Keeping the type attribute names in the types symtab in the kernel
>>> policy allows tools like audit2why and apol to extract the original
>>> attribute names and display them.  I originally shed them because the
>>> kernel didn't need to use that information and we don't want
>>> attribute names to be used in security contexts, but it costs us
>>> little to save them and check for them, and it benefits the tools.
> 
> No, I got that part. What I was missing was that we identified
> attributes differently in modules and kernel policy now, kind of
> confusing.

I see, modular policy format now has "primary", "flavor" and "flags"
members to identify its properties. It is different from newer kernel
policy format.

>> The type_datum has the following format in the newer kernel policy:
>>
>>   +0 +-------------------------+
>>      | length of name          |
>>   +4 +-------------------------+
>>      | type identifier value   |
>>   +8 +-------------------------+
>>      | property bits           | <--- TYPEDATUM_PROPERTY_PRIMARY
>> +12 +-------------------------+      TYPEDATUM_PROPERTY_ATTRIBUTE
>>      | bounds type identifier  |
>> +16 +-------------------------+
>>      | text representation of  |
>>      | name (variable length)  |
>>      +-------------------------+
>>
>> Any property bits are packed within the third field.
>>
> 
> I don't see that in the libsepol patch:
> 
> @@ -145,8 +146,16 @@
>  	ebitmap_t types;	/* types with this attribute */
>  #define TYPE_FLAGS_PERMISSIVE	0x01
>  	uint32_t flags;
> +	uint32_t bounds;	/* bounds type, if exist */
>  } type_datum_t;

Are you saying members within type_datum_t should have one-to-one mapping
with its disk format? If so, it is the most straightforward approach to
add a "flavor" member for the disk format of kernel policy.

I guess your opinion is that smaller differences between kernel and
modular policy format is better. If so, what do you think about an idea
which packs all properties of a type into a property bits members.
We need 1 bit for "primary" property, 2 bits for "flavor" and 1 bit for
"permissive", so it is enough to store them into a 32bits variable.

In this case, the format of type_datum is changed as follows:

  + 0 : length of name (unchanged)
  + 4 : type identifier value (unchanged)
  + 8 : property bits which can have following bits
  +12 : bounds type identifier (newly added)
  +16 : ebitmap of attributes (modular only/unchanged)
  +XX : text representation of type name
  (*) flavor in modular policy format is deprecated.

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