In kernel 4.7, the capability and capability2 classes were split apart
from cap_userns and cap2_userns (see kernel commit
8e4ff6f228e4722cac74db716e308d1da33d744f). Since then, Android cannot be
run in a container with SELinux in enforcing mode.
This change applies the existing capability rules to user namespaces as
well as the root namespace so that Android running in a container
behaves the same on pre- and post-4.7 kernels.
This is essentially:
1. New global_capability_class_set and global_capability2_class_set
that match capability+cap_userns and capability2+cap2_userns,
respectively.
2. s/self:capability/self:global_capability_class_set/g
3. s/self:capability2/self:global_capability2_class_set/g
4. Add cap_userns and cap2_userns to the existing capability_class_set
so that it covers all capabilities. This set was used by several
neverallow and dontaudit rules, and I confirmed that the new
classes are still appropriate.
Test: diff new policy against old and confirm that all new rules add
only cap_userns or cap2_userns;
Boot ARC++ on a device with the 4.12 kernel.
Bug: crbug.com/754831
Change-Id: I4007eb3a2ecd01b062c4c78d9afee71c530df95f
Only getattr and read are necessary for lnk_file. Open violates a new
neverallow for separating system and vendor data.
Bug: 34980020
Test: Enroll fingerprint on Taimen
Change-Id: I9434afbd5b4ecc1ead9f0ba47c7582fb5a6c6bf0
This attribute is being actively removed from policy. Since
attributes are not being versioned, partners must not be able to
access and use this attribute. Move it from private and verify in
the logs that rild and tee are not using these permissions.
Bug: 38316109
Test: build and boot Marlin
Test: Verify that rild and tee are not being granted any of these
permissions.
Change-Id: I31beeb5bdf3885195310b086c1af3432dc6a349b
We install all default hal implementations in /vendor/bin/hw along with
a few domains that are defined in vendor policy and installed in
/vendor. These files MUST be a subset of the global 'vendor_file_type'
which is used to address *all files installed in /vendor* throughout the
policy.
Bug: 36463595
Test: Boot sailfish without any new denials
Change-Id: I3d26778f9a26f9095f49d8ecc12f2ec9d2f4cb41
Signed-off-by: Sandeep Patil <sspatil@google.com>
SELinux policy no longer has allow rules which permit core/non-vendor
domains to communicate with tee domain over sockets. This commit thus
removes tee from the list of temporary exceptions for the socket
communications prohibition.
Test: mmm system/sepolicy
Bug: 36714625
Bug: 36715266
Change-Id: Iccbd9ea0555b0c9f1cb6c5e0f5a6c0d3f8730b4d
"tee" domain is a vendor domain. Hence its rules should live on the
vendor image.
What's left as public API is that:
1. tee domain exists and that it is permitted to sys_rawio capability,
2. tee_device type exists and apps are not permitted to access
character devices labeled tee_device.
If you were relying on system/sepolicy automatically labeling
/dev/tf_driver as tee_device or labeling /system/bin/tf_daemon as
tee_exec, then you need to add these rules to your device-specific
file_contexts.
Test: mmm system/sepolicy
Test: bullhead, angler, and sailfish boot up without new denials
Bug: 36714625
Bug: 36714625
Bug: 36720355
Change-Id: Ie21619ff3c44ef58675c369061b4afdd7e8501c6
