On 09/22/2014 08:54 AM, Joshua Brindle wrote: > Stephen Smalley wrote: >> On 09/19/2014 05:59 PM, William Roberts wrote: >>> On Fri, Sep 19, 2014 at 2:41 PM, William Roberts >>> <[email protected]> wrote: >>>> On Fri, Sep 19, 2014 at 2:40 PM, William Roberts >>>> <[email protected]> wrote: >>>>> They could get a similair result with UNION + IGNORE (Filter). I can >>>>> say I have seen valid uses of REPLACE. Perhaps the issue here is that >>>>> we don't want them to override certain files. If the neverallow rules >>>>> stayed in one file, we could error out if they tried to replace them >>>>> or filter them. >>>>> >>>>> But at the end of the day, if their building from source they could >>>>> just change those two, but an expicit warning may cause them to >>>> Sorry hard to read here. "two" should be "too". As in they can change >>>> the source code too. >>>>> re-think their approach. >>>>> >>>>> This might be just crazy here, because this approach is a bit more >>>>> cumbersome. What if we made the neverallow rules part of the compiled >>>>> policy and then have CTS read those out and check against the AOSP >>>>> policy? Again, though they have the source and could just lie to CTS >>>>> or embed phony never allow rules... IDK. >>>>> >>> As I think a bit more, I thought CTS had some type of never-allow rule >>> checker by reading the never-allows from AOSP >>> and seeing if any rules were granted, did this not happen? >>> >>> Are the CTS failures your seeing the Policy Check failures or >>> something else failing? >> >> Yes, that is part of SELinuxTest.java. Confirms that none of the >> neverallow rules extracted from the AOSP policy into selinux_policy.xml >> are not violated. However, as it necessarily pre-expands the attributes >> into domains at build time, it only checks the AOSP domains for >> violations. Any device-specific domain will not be checked by this >> test, at least as it exists currently. > > Having worked on policies for non-AOSP devices I can say that some > phones will not function without adding exceptions to the neverallow > rules. We aren't constrained by CTS so I don't know what the effect > would be but presumably the vendor policies would also need such > exceptions. We aren't building in an AOSP tree anymore so we just add > exception attributes at the top layer. There should probably be > exception attributes for things that often need to be added (e.g., set > system_prop). I don't know if CTS allows explanations for things but > could just extract all the types from the exception attribute an ask for > an explanation? > > Why does the tool necessarily pre-expand attributes? All the attribute > information is present in policies these days.
The cts test works by invoking checkSELinuxAccess on each (scontext, tcontext, class, permission) tuple, so it needs individual domains and types. Advantages: - No need for libsepol on device, - No need to directly read the kernel binary policy from an app, - Will inherently fail neverallow checks on any permissive domains because they will return success on all checkSELinuxAccess calls (which would not normally be caught by the normal libsepol neverallow checker). OTOH, AOSP separately merged an extension to sepolicy-check to permit checking for permissive domains and a change to policy to allow reading of the kernel policy via /sys/fs/selinux/policy, so it is unclear to me that we are gaining much (assuming that this check was somehow tied into CTS, but I don't see that currently). _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
