On 09/22/2014 09:23 AM, William Roberts wrote: > If something fails in CTS, OEMs can ask for an exception. I've never had to > do one personally. But IMO I would rather have an OEM submit for exception > on neverallow violation, and verify the security impact of their change > rather than submitting a device with broken WiFi. > > At the same time. If others are having this CTS selinux test fail, let's > work on making it more comprehensive. > > What happens if no standard AOSP domains are found, does the test fail?
The separate SELinuxDomainTest ensures that the core AOSP daemons are running in the expected domains. But not anything about device-specific daemons/domains. > I would argue for leaving REPLACE since its only compile time and you're > not proposing to axe IGNORE as well, which I would be opposed to as well. > Wouldn't it be better to move the assertions to one policy and throw build > error on trying to REPLACE or IGNORE on assert.te? Again trivial to bypass. I'm inclined to keep it as well. We originally did have the neverallow rules in a separate assert.te file and then AOSP split it up among the individual .te files. We could retain per-domain modularity by moving them to a <domain>_assert.te file, e.g. domain_assert.te, vold_assert.te. Changing external/sepolicy/Android.mk to impose a restrictions on REPLACE/IGNORE of anything ending in _assert.te would seem straightforward, although as you note in the end nothing prevents the truly determined person from bypassing even that. Separately, I think we likely want to augment the CTS to apply the neverallow checks on all domains, not just the core AOSP domains, but there we will especially need a standard way of defining exceptions. And then those exceptions can perhaps be whitelisted in the CTS? _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
