uncrypt needs to be able to read OTA files in GMS core's home
directory, which is protected with MLS. Mark uncrypt as an
mlstrustedsubject so that it can read the files.
Addresses the following denial (and probably others):
uncrypt : type=1400 audit(0.0:27): avc: denied { getattr } for path="/data/data/com.google.android.gms" dev="mmcblk0p30" ino=81970 scontext=u:r:uncrypt:s0 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=dir
Remove the auditallow line for uncrypt. Per dd053a9b89,
the auditallow line was added to confirm that uncrypt was actually
accessing the userdata block device. The access to the userdata block
device is definitely occurring, and auditing it doesn't add any value.
Remove the auditing.
Eliminates the following unnecessary audit lines:
avc: granted { write } for pid=2449 comm="uncrypt" name="mmcblk0p31" dev="tmpfs" ino=10404 scontext=u:r:uncrypt:s0 tcontext=u:object_r:userdata_block_device:s0 tclass=blk_file
avc: granted { write open } for pid=2449 comm="uncrypt" path="/dev/block/mmcblk0p31" dev="tmpfs" ino=10404 scontext=u:r:uncrypt:s0 tcontext=u:object_r:userdata_block_device:s0 tclass=blk_file
Tighten up userdata block access to write-only. uncrypt never reads
directly from the block device.
Testing:
1) Create the file /cache/recovery/command with a line like:
--update_package=/data/data/com.google.android.gms/foo.zip
2) Create the file /data/data/com.google.android.gms/foo.zip
(contents not important)
3) Run "setprop ctl.start pre-recovery"
Expected: No SELinux denials.
Actual: SELinux denials
Bug: 18875451
Change-Id: I62c7f06313afb2535b0de8be3c16d9d33879dd5d
Introduce separate types for the userdata and cache block
devices so that we can assign them and allow access to them
in device-specific policy without allowing access to any other
block device (e.g. system). These types will only be used if
assigned to device node paths in the device-specific file_contexts
configuration. Otherwise, this change will have no impact - the
userdata and cache block devices will continue to default to block_device
type.
To avoid breakage when these new types are assigned to the userdata
block device, allow access by vold and uncrypt, but auditallow
these accesses to confirm that these are required.
Change-Id: I99d24f06506f51ebf1d186d9c393b3cad60e98d7
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Uncrypt needs search in /dev/block to open block devices.
Allow it.
Addresses the following denial:
[11105.601711] type=1400 audit(1393550350.528:30): avc: denied { search } for pid=14597 comm="uncrypt" name="block" dev="tmpfs" ino=7200 scontext=u:r:uncrypt:s0 tcontext=u:object_r:block_device:s0 tclass=dir
Change-Id: I4592784135a04ff5bff2715e1250661744f12aa1
Move the uncrypt domain into SELinux enforcing mode. This will
start enforcing SELinux rules; security policy violations will
return EPERM.
Bug: 13083922
Change-Id: I4805662d8b336e2bfd891237cc916c57179ebf12
Per https://android-review.googlesource.com/82814 , uncrypt
needs to be able to read shell_data_files on userdebug / eng
builds. Allow it.
Bug: 13083922
Change-Id: I72299673bb5e36be79413227105b5cad006d504f
Add initial support for uncrypt, started via the
pre-recovery service in init.rc. On an encrypted device,
uncrypt reads an OTA zip file on /data, opens the underlying
block device, and writes the unencrypted blocks on top of the
encrypted blocks. This allows recovery, which can't normally
read encrypted partitions, to reconstruct the OTA image and apply
the update as normal.
Add an exception to the neverallow rule for sys_rawio. This is
needed to support writing to the raw block device.
Add an exception to the neverallow rule for unlabeled block devices.
The underlying block device for /data varies between devices
within the same family (for example, "flo" vs "deb"), and the existing
per-device file_context labeling isn't sufficient to cover these
differences. Until I can resolve this problem, allow access to any
block devices.
Bug: 13083922
Change-Id: I7cd4c3493c151e682866fe4645c488b464322379
