First of all, thank you very much for a detailed reply!
>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.
I do agree that a proper policy should minimize an amount of exceptions
from "neverallow" rules, but given the amount of modifications by OEMs
Android normally has, I think it is unrealistic to assume that such
modifications won't be needed.
>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:
>neverallow { domain -debuggerd -vold -dumpstate -system_server }
>self:capability sys_ptrace;
>to:
>neverallow { domain -tracerdomains } self:capability sys_ptrace;
>after defining a tracerdomains attribute. And then just include
>tracerdomains as an attribute for all such domains. No need to modify
>external/sepolicy/domain.te or use BOARD_SEPOLICY_REPLACE to override it
>to add further exemptions once you have done that; you can just add a
>typeattribute <domain> tracerdomains; statement or add tracerdomains to
>the list of attributes in the type declaration for the domain in your
>device-specific policy.
>An alternative form would be to leave it as an explicit list for the
>domains defined in external/sepolicy and only use the attribute for the
>device-specific domains, e.g.: rewrite it as:
>neverallow { domain -debuggerd -vold -dumpstate -system_server
>-devicetracerdomains } self:capability sys_ptrace;
>with the devicetracerdomains attribute defined in external/sepolicy but
>only assigned to domains in the device-specific policy. That has the
>advantage of making the whitelisted domains explicit and fully visible
>in the neverallow rule for the core policy, while still allowing
>extensibility by device-specific policy.
I didn't know about the attribute possibility. I think it is a useful
feature, but as Nick mentioned in a thread, it might make things more
complex with one more layer of indirection and makes policy harder to
understand and manager.
>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.
I guess given a current state, I agree that this is the best way to go.
Maybe OEMs can help to build a list of the additional exceptions that would
be applicable in many cases and found across many devices.
Best Regards,
Elena
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
