When a bug causes us to leak a file descriptor or resource in the OTA
path, it can cause unremovable device-mapper devices. The companion CL
in this topic attempts to diagnose such problems by performing a quick
scan for things depending on an unremovable block device: mounts, loop
devices, and other device-mapper nodes.
To detect mounts it would normally be enough to scan /proc/mounts, but
with MNT_DETACH the filesystem may still be mounted but not visible to
update_engine. This is exactly what happened in b/184715543.
To scan for such cases, we look for /sys/fs/ext4/<name> or
/sys/fs/f2fs/<name> where <name> is the block device. To make this work,
we grant update_engine r_dir_perms to sysfs and sysfs_f2fs_dir. It
doesn't actually need to read the contents of any files, the presence of
the inode is good enough.
Bug: N/A
Test: manual test
Change-Id: Ib085c9c814180b360e2170135011261bbb7e35b6
Previously we would mount OTA images with a 'context=...' mount
option. This meant that all selinux contexts were ignored in the ota
image, limiting the usefulness of selinux in this situation. To fix
this the mount has been changed to not overwrite the declared contexts
and the policies have been updated to accurately describe the actions
being performed by an OTA.
Bug: 181182967
Test: Manual OTA of blueline
Merged-In: I5eb53625202479ea7e75c27273531257d041e69d
Change-Id: I5eb53625202479ea7e75c27273531257d041e69d
Restrict access to controlling snapuserd via ctl properties. Allow
update_engine to control snapuserd, and connect/write to its socket.
update_engine needs this access so it can create the appropriate dm-user
device (which sends queries to snapuserd), which is then used to build
the update snapshot.
This also fixes a bug where /dev/dm-user was not properly labelled. As a
result, snapuserd and update_engine have been granted r_dir_perms to
dm_user_device.
Bug: 168554689
Test: full ota with VABC enabled
Change-Id: I1f65ba9f16a83fe3e8ed41a594421939a256aec0
In addition, allow shell to read this property.
Test: getprop -Z
Test: cts-tradefed run cts -m CtsGestureTestCases
and check /sdcard/device-info-files/PropertyDeviceInfo.deviceinfo.json
Bug: 169169031
Change-Id: Ib71b01bac326354696e159129f9dea4c2e918c51
Add ro.build.ab_update.gki.prevent_downgrade_{version,spl} for
update_engine to determine whether downgrade in kernel version or SPL is
considered an error or not.
Bug: 162623577
Test: update_engine_unittest
Test: apply OTA
Change-Id: If602924d50a2d5cfb3c256b82491c413a9d39f9d
This is previously needed by snapshotctl to initiate the merge,
but now update_engine is responsible for initiating the merge.
Bug: 147696014
Test: no selinux denial on boot.
Change-Id: I7804af1354d95683f4d05fc5593d78602aefe5a7
- /data/gsi/ota/* now has the type ota_image_data_file. At runtime
during an OTA, update_engine uses libsnapshot to talk to gsid
to create these images as a backing storage of snapshots. These
"COW images" stores the changes update_engine has applied to
the partitions.
If the update is successful, these changes will be merged to the
partitions, and these images will be teared down. If the update
fails, these images will be deleted after rolling back to the
previous slot.
- /metadata/gsi/ota/* now has the type ota_metadata_file. At runtime
during an OTA, update_engine and gsid stores update states and
information of the created snapshots there. At next boot, init
reads these files to re-create the snapshots.
Beside these assignments, this CL also allows gsid and update_engine
to have the these permissions to do these operations.
Bug: 135752105
Test: apply OTA, no failure
Change-Id: Ibd53cacb6b4ee569c33cffbc18b1b801b62265de
Domains that access super_block_device should instead
access super_block_device_type, which includes appropriate
block devices for retrofit DAP devices.
Test: boots (sanity)
Test: manual OTA
Bug: 128991918
Change-Id: Ie025b1e3c17e82330042aaa4a3e2e4a02ec1265b
Update_engine reports metrics with libmerticslogger, which switches to
write to statsd recently. Add the permission to update_engine_common so
that both the daemon and recovery sideload tool can report the metrics.
update_engine: type=1400 audit(0.0:47): avc: denied { write } for name="statsdw" dev="tmpfs" ino=26257 scontext=u:r:update_engine:s0 tcontext=u:object_r:statsdw_socket:s0 tclass=sock_file permissive=0
update_engine: type=1400 audit(0.0:54): avc: denied { write } for name="statsdw" dev="tmpfs" ino=26257 scontext=u:r:update_engine:s0 tcontext=u:object_r:statsdw_socket:s0 tclass=sock_file permissive=0
Bug: 120623435
Test: the denial message disappear
Change-Id: Ie6a7a179b4291ef8209c99de758862b25df2a02f
These ioctls are similar to BLKGETSIZE64; they return benign information
about the partition's alignment, and are used by liblp to optimally
align dynamic partition extents.
The system_block_device is included here because on retrofit devices,
the "super" partition is mapped to the system partition.
Test: manual OTA on retrofit device
Bug: 118506262
Change-Id: I3dd3c99d86d63f97bcd393cff374e27f5ed2da2e
Update engine is responsible for updating various partitions, which
includes enabling or disabling the read-only bit on the underlying block
device.
Rather than try to list out each block device separately, generalize the
ioctl rules to apply to all block device nodes. If the ioctl permission
is granted via a normal allow rule, then the allowxperm statement will
allow BLKROGET and BLKROSET by default on those block devices.
Test: policy compiles
Bug: 118150702
Change-Id: I7bca52e0f442df7320748f6d6371e5016aa6dd0b
Allow BLKROGET and BLKROSET on the block devices underlying the /system
and rootfs partitions. As part of the Android boot process, the system
sets the block devices read-only to prevent accidental modification to
these partitions. Update engine needs the ability to adjust the block
device read-only flag in order to apply updates.
Addresses the following denials:
update_engine: type=1400 audit(0.0:96): avc: denied { ioctl } for path="/dev/block/sda33" dev="tmpfs" ino=15369 ioctlcmd=125e scontext=u:r:update_engine:s0 tcontext=u:object_r:system_block_device:s0 tclass=blk_file permissive=0
update_engine: type=1400 audit(0.0:97): avc: denied { ioctl } for path="/dev/block/sda33" dev="tmpfs" ino=15369 ioctlcmd=125d scontext=u:r:update_engine:s0 tcontext=u:object_r:system_block_device:s0 tclass=blk_file permissive=0
Test: policy compiles
Bug: 118150702
Change-Id: I65a3d041b6d6b7955bcd901637a543524fc34a06
Similar to the way we handle /dev/random and /dev/urandom, make
/proc/sys/kernel/random available to everyone.
hostname:/proc/sys/kernel/random # ls -laZ
total 0
dr-xr-xr-x 1 root root u:object_r:proc_random:s0 0 2017-11-20 19:02 .
dr-xr-xr-x 1 root root u:object_r:proc:s0 0 2017-11-20 18:32 ..
-r--r--r-- 1 root root u:object_r:proc_random:s0 0 2017-11-20 19:02 boot_id
-r--r--r-- 1 root root u:object_r:proc_random:s0 0 2017-11-20 19:02 entropy_avail
-r--r--r-- 1 root root u:object_r:proc_random:s0 0 2017-11-20 19:02 poolsize
-rw-r--r-- 1 root root u:object_r:proc_random:s0 0 2017-11-20 19:02 read_wakeup_threshold
-rw-r--r-- 1 root root u:object_r:proc_random:s0 0 2017-11-20 19:02 urandom_min_reseed_secs
-r--r--r-- 1 root root u:object_r:proc_random:s0 0 2017-11-20 19:02 uuid
-rw-r--r-- 1 root root u:object_r:proc_random:s0 0 2017-11-20 19:02 write_wakeup_threshold
boot_id (unique random number per boot) is commonly used by
applications, as is "uuid". As these are random numbers, no sensitive
data is leaked. The other files are useful to allow processes to
understand the state of the entropy pool, and should be fairly benign.
Addresses the following denial:
type=1400 audit(0.0:207): avc: denied { read } for name="boot_id"
dev="proc" ino=76194 scontext=u:r:untrusted_app_25:s0:c512,c768
tcontext=u:object_r:proc:s0 tclass=file permissive=0
Bug: 69294418
Test: policy compiles.
Change-Id: Ieeca1c654ec755123e19b4693555990325bd58cf
New types:
1. proc_random
2. sysfs_dt_firmware_android
Labeled:
1. /proc/sys/kernel/random as proc_random.
2. /sys/firmware/devicetree/base/firmware/android/{compatible, fstab,
vbmeta} as sysfs_dt_firmware_android.
Changed access:
1. uncrypt, update_engine, postinstall_dexopt have access to generic proc
and sysfs labels removed.
2. appropriate permissions were added to uncrypt, update_engine,
update_engine_common, postinstall_dexopt.
Bug: 67416435
Bug: 67416336
Test: fake ota go/manual-ab-ota runs without denials
Test: adb sideload runs without denials to new types
Change-Id: Id31310ceb151a18652fcbb58037a0b90c1f6505a
Grant update_engine access to sysfs.
Ran fake ota go/manual-ab-ota, and this denial was fixed:
avc: denied { read } for pid=912 comm="update_engine" name="compatible"
dev="sysfs" ino=17399 scontext=u:r:update_engine:s0
tcontext=u:object_r:sysfs:s0 tclass=file permissive=0
Test: boots with no new denials
Change-Id: I8697da3af254aea1cec44d9dbb1eca18be31859c
Remove "granted" logspam. Grante the observed permissions to the
individual processes that need them and remove the permission from
domain_deprecated.
avc: granted { read open } for comm="ndroid.settings"
path="/proc/version" dev="proc" ino=4026532081
scontext=u:r:system_app:s0 tcontext=u:object_r:proc:s0 tclass=file
avc: granted { getattr } for comm=4173796E635461736B202332
path="/proc/pagetypeinfo" dev="proc" ino=4026532129
scontext=u:r:system_app:s0 tcontext=u:object_r:proc:s0 tclass=file
avc: granted { read open } for comm="uncrypt" path="/proc/cmdline"
dev="proc" ino=4026532072 scontext=u:r:uncrypt:s0
tcontext=u:object_r:proc:s0 tclass=file
avc: granted { read open } for comm="update_engine"
path="/proc/sys/kernel/random/boot_id" dev="proc" ino=15852829
scontext=u:r:update_engine:s0 tcontext=u:object_r:proc:s0 tclass=file
avc: granted { read open } for comm="tiveportallogin"
path="/proc/vmstat" dev="proc" ino=4026532130
scontext=u:r:platform_app:s0:c512,c768 tcontext=u:object_r:proc:s0
tclass=file
This change is specifically not granting the following since it
should not be allowed:
avc: granted { read open } for comm="crash_dump64"
path="/proc/filesystems" dev="proc" ino=4026532416
scontext=u:r:dex2oat:s0 tcontext=u:object_r:proc:s0 tclass=file
avc: granted { read } for comm="crash_dump64" name="filesystems"
dev="proc" ino=4026532416 scontext=u:r:dex2oat:s0
tcontext=u:object_r:proc:s0 tclass=file
avc: granted { getattr } for comm="crash_dump64"
path="/proc/filesystems" dev="proc" ino=4026532416
scontext=u:r:dex2oat:s0 tcontext=u:object_r:proc:s0 tclass=file
Bug: 64032843
Bug: 28760354
Test: build
Change-Id: Ib309e97b6229bdf013468dca34f606c0e8da96d0
This fixes the following denial in O:
update_engine: type=1400 audit(0.0:2100): avc: denied { sigkill } for scontext=u:r:update_engine:s0 tcontext=u:r:postinstall:s0 tclass=process permissive=0
Bug: 35111618
Test: update_engine_client --cancel during postinstall
Change-Id: I7456a95b5ca6fbdb268a5e16a13e2409758141f5
Label /proc/misc and allow access to untrusted_apps targeting older API
versions, as well as update_engine_common.
/proc/misc is used by some banking apps to try to detect if they are
running in an emulated environment.
TODO: Remove access to proc:file from update_engine_common after more
testing.
Bug: 35917228
Test: Device boots and no new denials.
Change-Id: If1b97a9c55a74cb74d1bb15137201ffb95b5bd75
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
