Stephen Smalley wrote:
On 09/19/2014 05:59 PM, William Roberts wrote:
On Fri, Sep 19, 2014 at 2:41 PM, William Roberts
<[email protected]> wrote:
On Fri, Sep 19, 2014 at 2:40 PM, William Roberts
<[email protected]> wrote:
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
Sorry hard to read here. "two" should be "too". As in they can change
the source code too.
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.
As I think a bit more, I thought CTS had some type of never-allow rule
checker by reading the never-allows from AOSP
and seeing if any rules were granted, did this not happen?
Are the CTS failures your seeing the Policy Check failures or
something else failing?
Yes, that is part of SELinuxTest.java. Confirms that none of the
neverallow rules extracted from the AOSP policy into selinux_policy.xml
are not violated. However, as it necessarily pre-expands the attributes
into domains at build time, it only checks the AOSP domains for
violations. Any device-specific domain will not be checked by this
test, at least as it exists currently.
Having worked on policies for non-AOSP devices I can say that some
phones will not function without adding exceptions to the neverallow
rules. We aren't constrained by CTS so I don't know what the effect
would be but presumably the vendor policies would also need such
exceptions. We aren't building in an AOSP tree anymore so we just add
exception attributes at the top layer. There should probably be
exception attributes for things that often need to be added (e.g., set
system_prop). I don't know if CTS allows explanations for things but
could just extract all the types from the exception attribute an ask for
an explanation?
Why does the tool necessarily pre-expand attributes? All the attribute
information is present in policies these days.
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
