file_context files need to be explicitly labeled as they are now split
across system and vendor and won't have the generic world readable
'system_file' label.
Bug: 36002414
Test: no new 'file_context' denials at boot complete on sailfish
Test: successfully booted into recovery without denials and sideloaded
OTA update.
Test: ./cts-tradefed run singleCommand cts --skip-device-info \
--skip-preconditions --skip-connectivity-check --abi \
arm64-v8a --module CtsSecurityHostTestCases -t \
android.security.cts.SELinuxHostTest#testAospFileContexts
Change-Id: I603157e9fa7d1de3679d41e343de397631666273
Signed-off-by: Sandeep Patil <sspatil@google.com>
This is a special file that can be mounted as a loopback device to
exercise adoptable storage code on devices that don't have valid
physical media. For example, they may only support storage media
through a USB OTG port that is being used for an adb connection.
avc: denied { read } for path="/data/misc/vold/virtual_disk" dev="sda35" ino=508695 scontext=u:r:kernel:s0 tcontext=u:object_r:vold_data_file:s0 tclass=file permissive=0
Bug: 34903607
Change-Id: I84721ec0e9495189a7d850461875df1839826212
Per loop(4), this device is the preferred way of allocating new
loop devices since Linux 3.1.
avc: denied { read write } for name="loop-control" dev="tmpfs" ino=15221 scontext=u:r:vold:s0 tcontext=u:object_r:device:s0 tclass=chr_file permissive=0
Bug: 34903607
Change-Id: I1f5f62cf0a1c24c6f6453100004812af4b8e1503
We simplified the way we track whether or not a dex file is used by
other apps. DexManager in the framework keeps track of the data and we
no longer need file markers on disk.
Test: device boots, foreign dex markers are not created anymore
Bug: 32871170
Change-Id: I464ed6b09439cf0342020ee07596f9aa8ae53b62
This switches Keymaster HAL policy to the design which enables us to
conditionally remove unnecessary rules from domains which are clients
of Keymaster HAL.
Domains which are clients of Keymaster HAL, such as keystore and vold
domains, are granted rules targeting hal_keymaster only when the
Keymaster HAL runs in passthrough mode (i.e., inside the client's
process). When the HAL runs in binderized mode (i.e., in another
process/domain, with clients talking to the HAL over HwBinder IPC),
rules targeting hal_keymaster are not granted to client domains.
Domains which offer a binderized implementation of Keymaster HAL, such
as hal_keymaster_default domain, are always granted rules targeting
hal_keymaster.
Test: Password-protected sailfish boots up and lock screen unlocks --
this exercises vold -> Keymaster HAL interaction
Test: All Android Keystore CTS tests pass -- this exercises keystore ->
Keymaster HAL interaction:
make cts cts-tradefed
cts-tradefed run singleCommand cts --skip-device-info \
--skip-preconditions --skip-connectivity-check --abi arm64-v8a \
--module CtsKeystoreTestCases
Bug: 34170079
Change-Id: I2254d0fdee72145721654d6c9e6e8d3331920ec7
This adds the premissions required for
android.hardware.keymaster@2.0-service to access the keymaster TA
as well as for keystore and vold to lookup and use
android.hardware.keymaster@2.0-service.
IT DOES NOT remove the privileges from keystore and vold to access
the keymaster TA directly.
Test: Run keystore CTS tests
Bug: 32020919
(cherry picked from commit 5090d6f324)
Change-Id: Ib02682da26e2dbcabd81bc23169f9bd0e832eb19
This neverallow addition addresses the renaming of files in exploits in
order to bypass denied permissions. An example of a similar use case of
using mv to bypass permission denials appeared in a recent project zero
ChromeOS exploit as one of the steps in the exploit chain.
https://googleprojectzero.blogspot.com/2016/12/chrome-os-exploit-one-byte-overflow-and.html
Additionally, vold and init both had permission sets that allowed them
to rename, but neither of them seem to need it. Therefore the rename
permission has also been removed from these two .te files.
Test: The device boots successfully
Change-Id: I07bbb58f058bf050f269b083e836c2c9a5bbad80
There is no reason for vold to have this permission, and a proper
auditallow rule has been used and monitored to ensure that nothing on
android uses this permission.
Bug: 26901147
Test: Phone boots
Change-Id: Id36ed2722348f433fe3d046a3429066338230fec
Vold shouldn't have this selinux permission, so this will be left in for
a few weeks to keep track of if removing it would be an issue to any
other processes. If not, then a follow-up CL will remove both the rule
and the auditallow
Test: This CL is a test in itself, auditallow rules shouldn't change
behavior of SELinux policy by themselves
Bug: 26901147
Change-Id: Ib076448863bd54278df59a3b514c9e877eb22ee5
Divide policy into public and private components. This is the first
step in splitting the policy creation for platform and non-platform
policies. The policy in the public directory will be exported for use
in non-platform policy creation. Backwards compatibility with it will
be achieved by converting the exported policy into attribute-based
policy when included as part of the non-platform policy and a mapping
file will be maintained to be included with the platform policy that
maps exported attributes of previous versions to the current platform
version.
Eventually we would like to create a clear interface between the
platform and non-platform device components so that the exported policy,
and the need for attributes is minimal. For now, almost all types and
avrules are left in public.
Test: Tested by building policy and running on device.
Change-Id: Idef796c9ec169259787c3f9d8f423edf4ce27f8c
