Stop using these SELinux attributes since the apexd and init SELinux
policies no longer rely on these attributes.
The difference between the previous versions of this patch and the
current patch is that the current patch does not remove any SELinux
attributes. See also
https://android-review.googlesource.com/c/platform/system/sepolicy/+/1850656.
See also
https://android-review.googlesource.com/c/platform/system/sepolicy/+/1862919.
This patch includes a revert of commit 8b2b951349 ("Restore permission
for shell to list /sys/class/block"). That commit is no longer necessary
since it was a bug fix for the introduction of the sysfs_block type.
Bug: 202520796
Test: source build/envsetup.sh && lunch aosp_x86_64 && m && launch_cvd
Change-Id: I73e1133af8146c154af95d4b96132e49dbec730c
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Remove these SELinux attributes since the apexd and init SELinux policies
no longer rely on these attributes.
The only difference between a previous version of this patch and the
current patch is that the current patch moves these attributes to the
'compat' policy. See also
https://android-review.googlesource.com/c/platform/system/sepolicy/+/1850656.
This patch includes a revert of commit 8b2b951349 ("Restore permission
for shell to list /sys/class/block"). That commit is no longer necessary
since it was a bug fix for the introduction of the sysfs_block type.
Bug: 202520796
Test: source build/envsetup.sh && lunch aosp_x86_64 && m && launch_cvd && adb -e shell dmesg | grep avc
Change-Id: Id7d32a914e48bc74da63d87ce6a09f11e323c186
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Revert "Remove the bdev_type and sysfs_block_type SELinux attributes"
Revert "Remove the bdev_type and sysfs_block_type SELinux attributes"
Revert submission 1850578-remove-selinux-bdev-type
Reason for revert: DroidMonitor-triggered revert due to breakage, bug b/203480787
BUG: 203480787
Reverted Changes:
I263bce9c4:Remove the bdev_type and sysfs_block_type SELinux ...
Ibc9039f96:Revert "Add the 'bdev_type' attribute to all block...
Ic6ae83576:Remove the bdev_type and sysfs_block_type SELinux ...
Ie493022a8:Remove the bdev_type and sysfs_block_type SELinux ...
I1f1ca439b:Revert "Add the 'bdev_type' attribute to all block...
I283f8676b:Revert "Add the 'bdev_type' attribute to all block...
I7c5c242c5:Revert "Add the 'bdev_type' attribute to all block...
Id78d8f7dc:Remove the bdev_type and sysfs_block_type SELinux ...
I9c4b2c48b:Remove the bdev_type and sysfs_block_type SELinux ...
I51e9d384a:Remove the bdev_type and sysfs_block_type SELinux ...
I2c414de3b:Remove the sysfs_block_type SELinux attribute
Change-Id: I55609803d530772d507d9dca8ba202a96daf24b7
Remove these SELinux attributes since adding these attributes introduces
a depencency from vendor SELinux policies on the generic SELinux policy,
something that is not allowed. This patch includes a revert of commit
8b2b951349 ("Restore permission for shell to list /sys/class/block").
That commit is no longer necessary since it was a bug fix for the
introduction of the sysfs_block type.
Bug: 202520796
Test: source build/envsetup.sh && lunch aosp_x86_64 && m && launch_cvd
Change-Id: Ic6ae835768212648ca09fd5c83c39180103c3b1b
Signed-off-by: Bart Van Assche <bvanassche@google.com>
Addressing b/194450129 requires configuring the I/O scheduler and the
queue depth of loop devices. Doing this in a generic way requires
iterating over the block devices under /sys/class/block and also to
examine the properties of the boot device (/dev/sda). Hence this patch
that allows 'init' and 'apexd' to read the properties of all block
devices. The patch that configures the queue depth is available at
https://android-review.googlesource.com/c/platform/system/core/+/1783847.
Test: Built Android images, installed these on an Android device and verified that modified init and apexd processes do not trigger any SELinux complaints.
Change-Id: Icb62449fe0d21b3790198768a2bb8e808c7b968e
Signed-off-by: Bart Van Assche <bvanassche@google.com>
In microdroid, apexd activates apexes which are passed as a virtual disk
to share apexes with host Android.
Bug: 184605708
Test: apexd running in microdroid can read /dev/block/vdb2
when a disk image is passed to crosvm via --disk= option.
Change-Id: Ie27774868a0e0befb4c42cff795d1531b042654c
This is intended so apps that are allowed access to uhid_device can pass
the mls constraints.
Bug: 183449317
Test: n/a
Change-Id: I8ca87014ddfd7e9a02a2ac97a13f2c43841ee181
One of the advantages of the DMA-BUF heaps framework over
ION is that each heap is a separate char device and hence
it is possible to create separate sepolicy permissions to restrict
access to each heap.
In the case of ION, allocation in every heap had to be done through
/dev/ion which meant that there was no away to restrict allocations in
a specific heap.
This patch intends to restrict coredomain access to only approved
categories of vendor heaps. Currently, the only identified category
as per partner feedback is the system-secure heap which is defined
as a heap that allocates from protected memory.
Test: Build, video playback works on CF with ION disabled and
without sepolicy denials
Bug: 175697666
Change-Id: I923d2931c631d05d569e97f6e49145ef71324f3b
Few domains are granted access to this, but they should have access
from any user.
Also add some neverallows to prevent misuse.
Bug: 170622707
Test: presubmits
Change-Id: Iacbe7b0525604f2339f8bf31c105af738bc3cd75
dm-user is a new device-mapper module, providing a FUSE-like service for
block devices. It creates control nodes as misc devices under
/dev/dm-user/. Make sure these nodes get a unique selabel.
snapuserd is a daemon for servicing requests from dm-user. It is a
low-level component of Virtual A/B updates, and provides the bridge
betewen dm-snapshot and the new COW format. For this reason it needs
read/write access to device-mapper devices.
Bug: 168259959
Test: ctl.start snapuserd, no denials
vts_libsnapshot_test, no denials
Change-Id: I36858a23941767f6127d6fbb9e6755c68b91ad31
Define the label dmabuf_system_heap_device for /dev/dma_heap/system.
This the default DMA-BUF heap that Codec2 will use one ION is
deprecated.
Test: video playback without denials with DMA-BUF heaps enabled
Bug: 168333162
Change-Id: Ief48165cd804bde00e1881a693b5eb44a45b633b
This grants default access to the new GNSS subsystem for Linux to the
GNSS HAL default implementation. The GNSS subsystem creates character
devices similar to ttys but without much unneeded complexity. The GNSS
device class is specific to location use cases.
Bug: 151670529
Change-Id: I03b27aa5bbfdf600eb830de1c8748aacb9bf4663
As suggested by nnk@, I have moved the definition for usb_serial_device
to system/sepolicy/public/device.te from
/system/sepolicy/public/hal_can.te.
See suggestion in aosp/1166865
Test: Manually bring up SLCAN device on test hardware with this change
in place
Change-Id: I0a11556a7eae0be2c9e4b090b051969566c2343e
This duplicated ashmem device is intended to replace ashmemd.
Ashmem fd has a label of the domain that opens it. Now with ashmemd
removed, ashmem fds can have labels other than "ashmemd", e.g.
"system_server". We add missing permissions to make ashmem fds usable.
Bug: 139855428
Test: boot device
Change-Id: Iec8352567f1e4f171f76db1272935eee59156954
To install GSIs on external storage (such as sdcards), gsid needs some
additional privileges:
- proc_cmdline and device-tree access to call ReadDefaultFstab().
This is ultimately used to check whether system's dm-verity has
check_at_most_once enabled, which is disallowed with sdcards.
- vfat read/write access to write files to the sdcard. Note that
adopted sdcards are not supported here.
- read access to the sdcard block device. To enable this without
providing access to vold_block_device, a new sdcard_block_device
label was added. Devices must apply this label appropriately to
enable gsid access.
- FIBMAP access for VFAT filesystems, as they do not support FIEMAP.
This only appears to work by granting SYS_RAWIO.
Bug: 126230649
Test: adb shell su root gsi_tool install --install_dir=/mnt/media_rw/...
works without setenforce 0
Change-Id: I88d8d83e5f61d4c0490f912f226fe1fe38cd60ab
This is the type used on super partition block devices.
- On devices launch with DAP, super is already marked
as super_block_device_type.
- On retrofit devices, appropriate block devices must
be marked as super_block_device_type, for example:
typeattribute system_block_device super_block_device_type;
Bug: 128991918
Test: builds
Change-Id: I7e26d85b577ce08d8dc1574ddc43146d65843d9c
After b/28357356 /dev/alarm is no longer used by android platform.
Also, Pixel devices don't have /dev/alarm.
Bug: 110962171
Test: boot aosp_walleye
Change-Id: Id9723996104a2548ddf366489890c098d1ea87be
cgroup is labeled from genfs_contexts. Also, cgroup filesystems can't be
context mounted, i.e. it's not possible to mount them with a label other
than "cgroup".
Bug: 110962171
Test: m selinux_policy
Test: boot aosp_walleye
Change-Id: I8319b10136c42a42d1edaee47b77ad1698e87f2c
mtd_device does not label any /dev node present on walleye, and the only
permission to that type is:
allow hal_telephony_server mtd_device:dir search;
I suspect there is no need to keep mtd_device around.
Bug: 110962171
Test: boot aosp_walleye
Change-Id: If74b1258b21edeca38c8b7dc07a3a10b751a7e85
No coredomain domain has access to these types and corresponding /dev
nodes don't exist on the device:
audio_seq_device
audio_timer_device
full_device
i2c_device
vcs_device
Bug: 110962171
Test: m selinux_policy
Test: boot walleye
Change-Id: I89ad4755e6760aa166cb22e2655567e5905dc672
The number of block devices used in an Android device is too damn high
(insert meme here). Let's at least add some links to documentation to
help describe the partition layout expected on a typical Android device.
This builds on top of the work in making the bootloader information
accessible (b/28905584).
Test: only adding comments. Policy compiles.
Change-Id: I8976b855e46255f7e18fa2b807ba83e0db92a82d
Bug: 78793464
Test: fastboot getvar partition-size:super
'super_block_device' corresponds to the super partition
required for flashing dynamic partitions.
Change-Id: I323634b6797ead7c5face117a7028bf9ab947aea
Allow init to create a serialized property_info file and allow all
processes to read it.
Bug: 36001741
Test: boot bullhead, walleye using property_info
Change-Id: Ie51d4c0f0221b128dd087029c811fda15b4d7093
Add /dev/kmsg_debug on userdebug devices, to allow crash_dump to log
crashes to dmesg when logd isn't up yet (or is the one crashing).
Bug: http://b/36574794
Test: stop tombstoned; crasher; dmesg
Change-Id: I6ffe11bc613e88198893e82712719522b74fe1be
This was marked deprecated in 2014 and removed in 2015, let's remove
the sepolicy now too.
Test: see that logging still works on bullhead
Change-Id: I4caa0dbf77956fcbc61a07897242b951c275b502
Add /dev/kmsg_debug on userdebug devices, to allow crash_dump to log
crashes to dmesg when logd isn't up yet (or is the one crashing).
Bug: http://b/36574794
Test: stop tombstoned; crasher; dmesg
Change-Id: I249e11291c58fee77098dec3fd3271ea23363ac9
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
vndservicemanager is the context manager for binder services
that are solely registered and accessed from vendor processes.
Bug: 36052864
Test: vendorservicemanager runs
Merged-In: Ifbf536932678d0ff13d019635fe6347e185ef387
Change-Id: I430f1762eb83825f6cd4be939a69d46a8ddc80ff
This switches Boot Control HAL policy to the design which enables us
to conditionally remove unnecessary rules from domains which are
clients of Boot Control HAL.
Domains which are clients of Boot Control HAL, such as update_server,
are granted rules targeting hal_bootctl only when the Boot Control 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_bootctl are not granted to client domains.
Domains which offer a binderized implementation of Boot Control HAL,
such as hal_bootctl_default domain, are always granted rules targeting
hal_bootctl.
P. S. This commit removes direct access to Boot Control HAL from
system_server because system_server is not a client of this HAL. This
commit also removes bootctrl_block_device type which is no longer
used. Finally, boot_control_hal attribute is removed because it is now
covered by the hal_bootctl attribute.
Test: Device boots up, no new denials
Test: Reboot into recovery, sideload OTA update succeeds
Test: Apply OTA update via update_engine:
1. make dist
2. Ensure device has network connectivity
3. ota_call.py -s <serial here> out/dist/sailfish-ota-*.zip
Bug: 34170079
Change-Id: I9c410c092069e431a3852b66c04c4d2a9f1a25cf
It seems likely that there is no reason to keep around a number of
devices that are configured to be included into the pixel kernels. Init
and ueventd should be the only processes with r/w access to these
devices, so auditallow rules have been added to ensure that they aren't
actually used.
/dev/keychord was given its own type since it's one of the few character
devices that's actually legitimately used and would cause log spam in
the auditallow otherwise.
Bug: 33347297
Test: The phone boots without any apparent log spam.
Change-Id: I3dd9557df8a9218b8c802e33ff549d15849216fb
Only init and ueventd have any access to /dev/port, and neither should
have any use for it. As it stands, leaving port in just represents
additional attack surface with no useful functionality, so it should be
removed if possible, not only from Pixel devices, but from all Android
devices.
Test: The phone boots successfully
Bug:33301618
Change-Id: Iedc51590f1ffda02444587d647889ead9bdece3f
urandom_device and random_device have the exact same security
properties. Collapse them into one type.
Test: device boots and /dev/urandom is labeled correctly.
Change-Id: I12da30749291bc5e37d99bc9422bb86cb58cec41
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
