[prev in list] [next in list] [prev in thread] [next in thread] 

List:       seandroid-list
Subject:    Re: fc ordering
From:       Stephen Smalley <sds () tycho ! nsa ! gov>
Date:       2016-01-04 19:47:34
Message-ID: 568ACC56.8070501 () tycho ! nsa ! gov
[Download RAW message or body]

On 01/04/2016 01:46 PM, Roberts, William C wrote:
>>>> <snip>
>>>>
>>>>>> libselinux only "sorts" in the sense of giving precedence to exact
>>>>>> (no regex characters) entries.  The sorting described in the page
>>>>>> you referenced is done by libsemanage or by the fc_sort helper
>>>>>> program used in the refpolicy build and is not part of Android at
>>>>>> all.  That sorting was introduced to help with ambiguities that
>>>>>> occur when file_contexts was split into per-module .fc files.
>>>>> That's essentially the problem we have in our build. Each module is
>>>>> added
>>> during the build via sepolicy dirs variable. Perhaps then we should
>>> look at adding fc_sort during build?
>>>>> Android however
>>>>>> only has a single monolithic file_contexts file, and even with the
>>>>>> device-specific file_contexts, the assumption is that those
>>>>>> entries should always take precedence over the generic ones (as
>>>>>> long as they are not identical and conflict).  So order does
>>>>>> matter.  Last matching entry wins.
>>>>
>>>> Does anyone object to adding something like sort_fc to the build to
>>>> alleviate
>>> this ordering issue?
>>>>
>>>> Now that we switch to checking the fc files with checkfc, I'm not
>>>> aware of any
>>> other CTS issues.
>>>
>>> I guess the question is whether we want to sort the entire
>>> file_contexts this way (which could potentially cause an entry from
>>> the AOSP general file_contexts to override a device-specific entry) or
>>> individually sort the general and device- specific file_contexts and
>>> then concatenate the two.  The sorting is heuristic- based, as there
>>> is no precise ordering that can be defined among regular expressions.
>>
>> IIUC,  If we sort the entire fc entries (general + device), then the heuristics per
>> that fedora page would allow "more specific" device entries to override general
>> entries.
>>
>> However, just sorting the device policy would also be Ok with me, since it would
>> solve my issue In the modular style policy build.
>>
>>>
>>>> BTW in the CTS test, why didn't we just modify checkfc to return
>>>> status codes
>>> for equal, subset, superset? We have all this "complicated"
>>>> stdio checking for exact matching.
>>>
>>> I followed the example of other tests which were output-based, and
>>> also exit status can be misleading, e.g. you have to ensure that you
>>> are not misinterpreting a shell exit code (e.g. checkfc could not be
>>> found or could not be
>>> executed) as the exit code of checkfc itself, and that you cleanly
>>> delineate all possible exit statuses of the program.
>
>
> I'm assuming silence means no one objects to doing this on Android, so now the question is
> Implementation. Looks as though libsemanage has some fc sorting code for this, do we use that
> or roll our own python script for this. The other thing, I can't find fc_sort or sort_fc, can someone
> point to where that source is?

refpolicy/support/fc_sort.c


_______________________________________________
Seandroid-list mailing list
Seandroid-list@tycho.nsa.gov
To unsubscribe, send email to Seandroid-list-leave@tycho.nsa.gov.
To get help, send an email containing "help" to Seandroid-list-request@tycho.nsa.gov.
[prev in list] [next in list] [prev in thread] [next in thread]