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? >> >> Bill >> >> >> On Fri, Sep 19, 2014 at 2:08 PM, Nick Kralevich <[email protected]> wrote: >>> >>> I'm really starting to get annoyed at BOARD_SEPOLICY_REPLACE. >>> >>> A few times now, I've seen people misusing this to bypass neverallow rules. >>> For example, just today I saw someone who copied over domain.te, commented >>> out a bunch of neverallow rules, then used "BOARD_SEPOLICY_REPLACE += >>> domain.te" to get their policy to compile. Not only do we have two copies of >>> domain.te floating around, people will be rudely surprised when their >>> devices fail CTS. >>> >>> I really want to get rid of this directive... I have yet to see one >>> legitimate use of this. >>> >>> Thoughts? >>> >>> -- >>> Nick Kralevich | Android Security | [email protected] | 650.214.4037 >>> >>> _______________________________________________ >>> Seandroid-list mailing list >>> [email protected] >>> To unsubscribe, send email to [email protected]. >>> To get help, send an email containing "help" to >>> [email protected]. >> >> >> >> -- >> Respectfully, >> >> William C Roberts > > > > -- > Respectfully, > > William C Roberts -- Respectfully, William C Roberts _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
