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-le...@tycho.nsa.gov.
To get help, send an email containing "help" to 
seandroid-list-requ...@tycho.nsa.gov.

Reply via email to