On Fri, Sep 12, 2014 at 6:37 AM, Stephen Smalley <[email protected]> wrote:
> Ideally it shouldn't need to scale because there should be very few if > any exceptions added to the set of neverallow rules in > external/sepolicy. When you encounter a neverallow failure, the first > step should be to see if you can avoid the need for the offending allow > rule altogether. This has happened for other cases in AOSP for the > device-specific daemons on the Nexus devices, for example. > +1 > > If we have a neverallow rule in external/sepolicy that we know will > require device-specific overrides, we can define and use an attribute in > writing the rule so that the device-specific policy can exempt its own > domains by adding the attribute to those domains, e.g. rewrite: > We've tried this in the past with the relabelto domain, and in retrospect, it just ended up causing more complexity than it solved. We ended up deleting it in https://android-review.googlesource.com/#/c/94000/ . While this approach is possible, I'd agree with you that we shouldn't follow this approach. I don't believe however that we should do this a priori for all of the > neverallow rules, as it makes it all too easy to subvert any/all of the > neverallow rules. Rather if/when OEMs find the need for an exception, > they can upload a change to external/sepolicy to rewrite the neverallow > rule along with the justification as to why it is necessary for > device-specific daemons, and the Android developers can assess the > change on its merits, possibly suggesting alternative means of solving > it without requiring such a change. > Agreed. -- 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].
