If something fails in CTS, OEMs can ask for an exception. I've never had to do one personally. But IMO I would rather have an OEM submit for exception on neverallow violation, and verify the security impact of their change rather than submitting a device with broken WiFi.
At the same time. If others are having this CTS selinux test fail, let's work on making it more comprehensive. What happens if no standard AOSP domains are found, does the test fail? I would argue for leaving REPLACE since its only compile time and you're not proposing to axe IGNORE as well, which I would be opposed to as well. Wouldn't it be better to move the assertions to one policy and throw build error on trying to REPLACE or IGNORE on assert.te? Again trivial to bypass. Bill On Sep 22, 2014 5:54 AM, "Joshua Brindle" <[email protected]> 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. > > >
_______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
