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
Bug: 62378620
Test: Android in Chrome OS can call uevent_kernel_recv() and not fail
with EIO.
Test: bullhead networking still works
Change-Id: I4dd5d2148ee1704c4fa23d7fd82d1ade19b58cbd
Prior to this CL, /sys/devices/virtual/block/dm-X was using the generic
sysfs label. This CL creates sysfs_dm label and grants the following
accesses:
- update_verifier to read sysfs_dm dir and file at
/sys/devices/virtual/block/dm-X.
- vold to write sysfs_dm.
Bug: 63440407
Test: update_verifier successfully triggers blocks verification and
marks a sucessful boot;
Test: No sysfs_dm related denials on sailfish.
Change-Id: I6349412707800f1bd3a2fb94d4fe505558400c95
On Marlin/Sailfish, StorageManager tests in CTS are exposing a bug
where the /proc/<pid>/ns/mnt files for system_server are briefly
mislabeled as "proc" instead of "system_server". Resulting in the
tests failing. Temporarily re-granting access to the default label
until the labeling issue can be tracked down.
Repro steps:
cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases \
-t android.os.storage.cts.StorageManagerTest
Failures:
android.os.storage.cts.StorageManagerTest#testOpenProxyFileDescriptor
fail: java.lang.IllegalStateException: command '58 appfuse mount 10065
959 0' failed with '400 58 Command failed'
android.os.storage.cts.StorageManagerTest#testOpenProxyFileDescriptor_async
fail: java.lang.IllegalStateException: command '59 appfuse mount 10065
959 1' failed with '400 59 Command failed'
android.os.storage.cts.StorageManagerTest#testOpenProxyFileDescriptor_error
fail: java.lang.IllegalStateException: command '60 appfuse mount 10065
959 2' failed with '400 60 Command failed'
From the log:
10-04 20:41:22.972 595 604 E vold : Failed to open namespace for
/proc/959/ns/mnt: Permission denied
10-04 20:41:22.967 604 604 W vold : type=1400 audit(0.0:90): avc:
denied { read } for dev="proc" ino=4026534249 scontext=u:r:vold:s0
tcontext=u:object_r:proc:s0 tclass=file permissive=0
10-04 20:41:23.051 604 604 W vold : type=1400 audit(0.0:91): avc:
denied { read } for dev="proc" ino=4026534249 scontext=u:r:vold:s0
tcontext=u:object_r:proc:s0 tclass=file permissive=0
10-04 20:41:23.054 595 604 E vold : Failed to open namespace for
/proc/959/ns/mnt: Permission denied
10-04 20:41:23.081 604 604 W vold : type=1400 audit(0.0:92): avc:
denied { read } for dev="proc" ino=4026534249 scontext=u:r:vold:s0
tcontext=u:object_r:proc:s0 tclass=file permissive=0
10-04 20:41:23.086 595 604 E vold : Failed to open namespace for
/proc/959/ns/mnt: Permission denied
sailfish:/ # ps -AZ | grep 959
u:r:system_server:s0 system 959 628 \
4557136 251500 SyS_epoll_wait 70e6df822c S system_server
The file labels appear to be correct when checked manually.
sailfish:/ # ls -lZ /proc/959/ns/
lrwxrwxrwx 1 system system u:r:system_server:s0 0 2017-10-04 17:19 mnt -> mnt:[4026534249]
lrwxrwxrwx 1 system system u:r:system_server:s0 0 2017-10-04 20:55 net -> net:[4026531906]
Bug: 67049235
Test: cts-tradefed run commandAndExit cts-dev -m CtsOsTestCases \
-t android.os.storage.cts.StorageManagerTes
Change-Id: Id4d200856c02c023c6f516e3f3bfa060e100086c
Raw sockets usually imply advanced parsers that might
have flaws. If vold need such odd thing, force it to have
that in a other domain like filesystem checks. Debug
features like ptrace does not belong to vold.
Bug: 64791922
Test: Manual
Change-Id: I75c62d13f998621f80b2049bce0505442862bf0b
Hardening vold. Vold has much rights to system sensitive parts and
are started by init. Enforce this security.
Bug: 64791922
Test: Manual
Change-Id: I077d251d1eb7b7292e1a4a785093cb7bf5524a83
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
Relabeling /vendor and /system/vendor to vendor_file removed
previously granted permissions. Restore these for non-treble devices.
Addresses:
avc: denied { execute_no_trans } for pid=2944 comm="dumpstate"
path="/system/vendor/bin/wpa_cli" dev="mmcblk0p10" ino=1929
scontext=u:r:dumpstate:s0 tcontext=u:object_r:vendor_file:s0
tclass=file
And potentially some other bugs that have yet to surface.
Bug: 37105075
Test: build Fugu
Change-Id: I8e7bd9c33819bf8206f7c110cbce72366afbcef8
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
