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