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. _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
