Thanks for the response and sorry for the delay; I was on a long
excursion to experience less sunlight than in a typical week (went on
vacation to see the eclipse, among other things), without much connectivity.
On 08/18/2017 10:38 AM, jwcart2 wrote:
On 08/17/2017 02:04 PM, Daniel Cashman wrote:
From: Dan Cashman <dcashman@xxxxxxxxxx>
In Android O, the SELinux policy was split from a monolithic policy
created at build-time for each device into two main components, one
on /system and one on /vendor, which get combined at boot. This
introduced several new challenges, including the creation of a need
to maintain compatibility between the two policies, i.e. new policy
on the /system image needs to work with the /vendor policy that is
based on the policy it's replacing, and updates to the /vendor policy
need to work with the /system policy.
The ultimate goal of this is to allow updates to /system without
changing /vendor. Android currently accomplishes this by exporting
'public' policy types that /vendor policy can use. It makes sure that
changes in object labels don't break the /vendor policy by changing all
public types into attributes, copying the public policy into the /vendor
policy and keepign a mapping between public types and the attributes
that are included in the /vendor policy.
This leads to complications, though, when trying to use different /system
images with the same /vendor image: the /vendor policy might rely on a
/system policy to provide a type definition or an attribute definition,
but another, non-customized /system policy might not provide it.
I can see were this can help prevent the policy failing to compile, but
it seems like there can still be run time problems. If one system policy
defines type A and has rules for type A and another doesn't, then, even
if the vendor policy defines type A (so there is no compile error), it
would still be missing the right allow rules and it could experience
runtime denials.
That being said, this could be useful in some cases, such as virus
scanning in Fedora's policy, where multiple modules would like to use
the same type and it might be possible to have more than one of them
loaded.
Jim
We hope to avoid runtime issues by copying the 'public' policy on which
the policy in the /vendor image may rely into that policy directly. As
a result, the allow rules are copied over as well (but the types are
converted to attributes to attempt to prevent other run-time breakage
due to changing labels). As an aside, "attribute-izing" can be seen in
the modifications to cil in libsepol here:
https://android.googlesource.com/platform/external/selinux/+/master/libsepol/cil/include/cil/android.h
which I'd also like to begin the process of upstreaming, but view as
independent of this patch.
It sounds like this would be acceptable in theory, so I'll fix up the
patch to address your comments and submit again.
Thanks,
Dan
