On 09/12/2014 03:25 AM, Elena Reshetova wrote:
> Hi,
>
> What is the recommended way to add more exceptions for an "neverallow" rule
> given that I don't want to touch the default policy file?
>
> The use case is that for example domain.te contains a lot of neverallow
> rules with some exceptions for the system daemons that are considered
> trusted to perform the defined operation.
>
> So, if somebody happen to add one more daemon that should belong to the
> exception list, what is the way to do it apart from either adding it to the
> existing domain.te or creating a full copy of domain.te, modifying it to
> contain the addition and then building the policy using this newly created
> domain.te?
>
> I don't think both methods are very flexible and scale well. What is really
> needed is a way to create a union on the list of neverallow rule
> exceptions.
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.
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 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.
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
