The sheer volume of these can cause confusion.
Sample denials (repeated for many processes):
denied { getattr } for path="/proc/1/status" dev="proc" ino=24427 scontext=u:r:performanced:s0 tcontext=u:r:init:s0 tclass=file permissive=1
denied { open } for path="/proc/1" dev="proc" ino=18608 scontext=u:r:performanced:s0 tcontext=u:r:init:s0 tclass=dir permissive=1
denied { open } for path="/proc/1/status" dev="proc" ino=24427 scontext=u:r:performanced:s0 tcontext=u:r:init:s0 tclass=file permissive=1
denied { read } for name="status" dev="proc" ino=24427 scontext=u:r:performanced:s0 tcontext=u:r:init:s0 tclass=file permissive=1
Bug: 72643420
Test: Denials no longer present in permissive mode.
Change-Id: Ic07b9b0b59ca2122c4843095b63075ab8fd2c70b
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
Sensord move in ag/2106763 should be accompanied by corresponding
sepolicy move of sensord-related files/declarations.
Bug: 36996994
Test: Sailfish build shows no related permission errors
Change-Id: Ibe41b363f7ca2752b5d3e0961298985cf784663d
Specify per-service rules for PDX transport. Now being able to
grant permissions to individual services provided by processes,
not all services of a process.
Also tighter control over which permissions are required for
client and server for individual components of IPC (endpoints,
channels, etc).
Bug: 37646189
Change-Id: I78eb8ae8b6e08105666445a66bfcbd2f1d69d0ea
vr_wm functionality is moved in VrCore, so remove this service.
Bug: 37542947, 36506799
Test: Ran on device and verified there are no permission errors while in
VR
Change-Id: I37fd34e96babec2a990600907f61da8c358ecc89
This set of rules is neeeded to allow vr_windows_manager to run
successfully on the system.
Bug: 32541196
Test: `m -j32` succeeds. Sailfish device boots.
Change-Id: I0aec94d80f655a6f47691cf2622dd158ce9e475f
