tequilaOS/platform_system_sepolicy
2
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
platform_system_sepolicy/uncrypt.te

33 lines
948 B
Text
Raw Normal View History

initial policy for uncrypt. 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
2014-02-19 22:33:32 +01:00
# uncrypt
uncrypt: fix OTAs 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 dd053a9b891195439b1c0848cb0e8a6e17b4b9bc, 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
2015-01-06 00:03:43 +01:00
type uncrypt, domain, mlstrustedsubject;
initial policy for uncrypt. 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
2014-02-19 22:33:32 +01:00
type uncrypt_exec, exec_type, file_type;
init_daemon_domain(uncrypt)
allow uncrypt self:capability dac_override;
# Read OTA zip file from /data/data/com.google.android.gsf/app_download
r_dir_file(uncrypt, app_data_file)
uncrypt: allow /data/local/tmp on userdebug/eng 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
2014-02-20 20:47:00 +01:00
userdebug_or_eng(`
# For debugging, allow /data/local/tmp access
r_dir_file(uncrypt, shell_data_file)
')
initial policy for uncrypt. 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
2014-02-19 22:33:32 +01:00
# Create tmp file /cache/recovery/command.tmp
# Read /cache/recovery/command
# Rename /cache/recovery/command.tmp to /cache/recovery/command
allow uncrypt cache_file:dir rw_dir_perms;
allow uncrypt cache_file:file create_file_perms;
# Set a property to reboot the device.
Replace unix_socket_connect() and explicit property sets with macro A common source of mistakes when authoring sepolicy is properly setting up property sets. This is a 3 part step of: 1. Allowing the unix domain connection to the init/property service 2. Allowing write on the property_socket file 3. Allowing the set on class property_service The macro unix_socket_connect() handled 1 and 2, but could be confusing for first time policy authors. 3 had to be explicitly added. To correct this, we introduce a new macros: set_prop(sourcedomain, targetprop) This macro handles steps 1, 2 and 3. No difference in sediff is expected. Change-Id: I630ba0178439c935d08062892990d43a3cc1239e Signed-off-by: William Roberts <william.c.roberts@linux.intel.com>
2015-05-05 03:22:45 +02:00
set_prop(uncrypt, powerctl_prop)
initial policy for uncrypt. 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
2014-02-19 22:33:32 +01:00
# Raw writes to block device
allow uncrypt self:capability sys_rawio;
allow uncrypt block_device:blk_file w_file_perms;
uncrypt: allow /dev/block directory access. 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
2014-02-28 02:24:43 +01:00
allow uncrypt block_device:dir r_dir_perms;
Define types for userdata and cache block devices. 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>
2014-09-11 14:50:04 +02:00
# Access userdata block device.
uncrypt: fix OTAs 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 dd053a9b891195439b1c0848cb0e8a6e17b4b9bc, 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
2015-01-06 00:03:43 +01:00
allow uncrypt userdata_block_device:blk_file w_file_perms;
Reference in a new issue Copy permalink