Re: [PATCH 02/10 v2] libsepol: Treat types like an attribute in the attr_type_map.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06/18/2015 04:21 PM, Stephen Smalley wrote:
> On 06/18/2015 04:16 PM, James Carter wrote:
>> On 06/18/2015 09:41 AM, Stephen Smalley wrote:
>>> Can you provide an example of the difference it makes?
>>>
>>
>> I'll add something like the following.
>>
>>
>> This allows the following statement:
>>
>> ebitmap_and(&m, &p->attr_type_map[src-1], &p->attr_type_map[tgt-1]);
>>
>>
>> which would have previously been written as:
>>
>> if (p->type_val_to_struct[src-1]->flavor == TYPE_ATTRIB &&
>>     p->type_val_to_struct[tgt-1]->flavor == TYPE_ATTRIB) {
>>     ebitmap_and(&m, &p->attr_type_map[src-1], &p->attr_type_map[tgt-1]);
>> } else if (p->type_val_to_struct[k->source_type - 1]->flavor ==
>> TYPE_ATTRIB) {
>>     if (ebitmap_get_bit(&p->attr_type_map[src-1], tgt-1)) {   
>>         ebitmap_set_bit(&m, tgt-1, 1);
>>     }
>> } else if (p->type_val_to_struct[tgt-1]->flavor == TYPE_ATTRIB) {
>>     if (ebitmap_get_bit(&p->attr_type_map[tgt-1], src-1)) {   
>>         ebitmap_set_bit(&m, src-1, 1);
>>     }
>> } else {
>>     if (src == tgt) {
>>         ebitmap_set_bit(&m, src-1, 1);
>>     }
>> }
> 
> Oh, you don't have to be that specific.  Could just note that this
> simplified the implementation of neverallow checking in assertion.c or
> something.
> 
> 
>>> I was wondering though if we are being inconsistent with type_attr_map.
>>>   We do set the type itself here upon policydb_read() of an existing
>>> kernel policy, but do we do it when first generating the type_attr_map
>>> by libsepol?
>>>
>>>
>>
>> I only see the type_attr_map being generated in policydb_read for a
>> kernel policy and when expand_module() is called. This surprised me and
>> made me think that there must be a better place to generate these
>> mappings, but I can't think of a better place. Can you?
> 
> No, I think it makes sense to generate it in the expand.c code (when
> generating the kernel policy from modules) and in policydb_read (when
> reading a kernel policy from a file/image).  But my question is whether
> we are consistently setting the type itself in both places.  You did
> that for attr_type_map, but are we doing it for type_attr_map?  And if
> not, why not?

Actually, I see that we do set it in expand_module before calling
hashtab_map on the type_attr_map callback function.  Whereas you do it
for attr_type_map within type_attr_map callback.
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.



[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux