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

33 lines
1.3 KiB
Text
Raw Normal View History

Do not allow init to execute anything without changing domains. Remove the ability of init to execute programs from / or /system without changing domains. This forces all helper programs and services invoked by init to be assigned their own domain. Introduce separate domains for running the helper programs executed from the fs_mgr library by init. This requires a domain for e2fsck (named fsck for generality) and a domain for running mkswap (named toolbox since mkswap is just a symlink to the toolbox binary and the domain transition occurs on executing the binary, not based on the symlink in any way). e2fsck is invoked on any partitions marked with the check mount option in the fstab file, typically userdata and cache but never system. We allow it to read/write the userdata_block_device and cache_block_device types but also allow it to read/write the default block_device type until we can get the more specific types assigned in all of the device-specific policies. mkswap is invoked on any swap partition defined in the fstab file. We introduce a new swap_block_device type for this purpose, to be assigned to any such block devices in the device-specific policies, and only allow it to read/write such block devices. As there seem to be no devices in AOSP with swap partitions in their fstab files, this does not appear to risk any breakage for existing devices. With the introduction of these domains, we can de-privilege init to only having read access to block devices for mounting filesystems; it no longer needs direct write access to such devices AFAICT. To avoid breaking execution of toolbox by system services, apps, or the shell, we allow all domains other than kernel and init the ability to run toolbox in their own domain. This is broader than strictly required; we could alternatively only add it to those domains that already had x_file_perms to system_file but this would require a coordinated change with device-specific policy. Change-Id: Ib05de2d2bc2781dad48b70ba385577cb855708e4 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
2014-09-23 15:11:30 +02:00
# Any toolbox command run by init.
# Do NOT use this domain for toolbox when run by any other domain.
toolbox: remove domain_deprecated attribute No "granted" messages for the removed permissions observed in three months of log audits. Bug: 28760354 Change-Id: I2b45284893e150575992befeef48e1bd53a2fba2
2016-09-13 06:19:22 +02:00
type toolbox, domain;
Introduce system_file_type system_file_type is a new attribute used to identify files which exist on the /system partition. It's useful for allow rules in init, which are based off of a blacklist of writable files. Additionally, it's useful for constructing neverallow rules to prevent regressions. Additionally, add commented out tests which enforce that all files on the /system partition have the system_file_type attribute. These tests will be uncommented in a future change after all the device-specific policies are cleaned up. Test: Device boots and no obvious problems. Change-Id: Id9bae6625f042594c8eba74ca712abb09702c1e5
2018-09-27 19:21:37 +02:00
type toolbox_exec, system_file_type, exec_type, file_type;
Do not allow init to execute anything without changing domains. Remove the ability of init to execute programs from / or /system without changing domains. This forces all helper programs and services invoked by init to be assigned their own domain. Introduce separate domains for running the helper programs executed from the fs_mgr library by init. This requires a domain for e2fsck (named fsck for generality) and a domain for running mkswap (named toolbox since mkswap is just a symlink to the toolbox binary and the domain transition occurs on executing the binary, not based on the symlink in any way). e2fsck is invoked on any partitions marked with the check mount option in the fstab file, typically userdata and cache but never system. We allow it to read/write the userdata_block_device and cache_block_device types but also allow it to read/write the default block_device type until we can get the more specific types assigned in all of the device-specific policies. mkswap is invoked on any swap partition defined in the fstab file. We introduce a new swap_block_device type for this purpose, to be assigned to any such block devices in the device-specific policies, and only allow it to read/write such block devices. As there seem to be no devices in AOSP with swap partitions in their fstab files, this does not appear to risk any breakage for existing devices. With the introduction of these domains, we can de-privilege init to only having read access to block devices for mounting filesystems; it no longer needs direct write access to such devices AFAICT. To avoid breaking execution of toolbox by system services, apps, or the shell, we allow all domains other than kernel and init the ability to run toolbox in their own domain. This is broader than strictly required; we could alternatively only add it to those domains that already had x_file_perms to system_file but this would require a coordinated change with device-specific policy. Change-Id: Ib05de2d2bc2781dad48b70ba385577cb855708e4 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
2014-09-23 15:11:30 +02:00
# /dev/__null__ created by init prior to policy load,
# open fd inherited by fsck.
allow toolbox tmpfs:chr_file { read write ioctl };
# Inherit and use pty created by android_fork_execvp_ext().
toolbox: android_fork_execvp_ext() requires getattr ioctl Addresses the following denials: avc: denied { getattr } for pid=148 comm="mkswap" path="/dev/pts/0" dev="devpts" ino=3 scontext=u:r:toolbox:s0 tcontext=u:object_r:devpts:s0 tclass=chr_file permissive=1 avc: denied { ioctl } for pid=148 comm="mkswap" path="/dev/pts/0" dev="devpts" ino=3 scontext=u:r:toolbox:s0 tcontext=u:object_r:devpts:s0 tclass=chr_file permissive=1 Change-Id: I88c88493cd5f523b5b26a8028b421b3565aa5751
2014-12-20 01:19:05 +01:00
allow toolbox devpts:chr_file { read write getattr ioctl };
Do not allow init to execute anything without changing domains. Remove the ability of init to execute programs from / or /system without changing domains. This forces all helper programs and services invoked by init to be assigned their own domain. Introduce separate domains for running the helper programs executed from the fs_mgr library by init. This requires a domain for e2fsck (named fsck for generality) and a domain for running mkswap (named toolbox since mkswap is just a symlink to the toolbox binary and the domain transition occurs on executing the binary, not based on the symlink in any way). e2fsck is invoked on any partitions marked with the check mount option in the fstab file, typically userdata and cache but never system. We allow it to read/write the userdata_block_device and cache_block_device types but also allow it to read/write the default block_device type until we can get the more specific types assigned in all of the device-specific policies. mkswap is invoked on any swap partition defined in the fstab file. We introduce a new swap_block_device type for this purpose, to be assigned to any such block devices in the device-specific policies, and only allow it to read/write such block devices. As there seem to be no devices in AOSP with swap partitions in their fstab files, this does not appear to risk any breakage for existing devices. With the introduction of these domains, we can de-privilege init to only having read access to block devices for mounting filesystems; it no longer needs direct write access to such devices AFAICT. To avoid breaking execution of toolbox by system services, apps, or the shell, we allow all domains other than kernel and init the ability to run toolbox in their own domain. This is broader than strictly required; we could alternatively only add it to those domains that already had x_file_perms to system_file but this would require a coordinated change with device-specific policy. Change-Id: Ib05de2d2bc2781dad48b70ba385577cb855708e4 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
2014-09-23 15:11:30 +02:00
# mkswap-specific.
# Read/write block devices used for swap partitions.
# Assign swap_block_device type any such partition in your
# device/<vendor>/<product>/sepolicy/file_contexts file.
allow toolbox block_device:dir search needed to get to the swap device. Addresses the following denial: avc: denied { search } for pid=149 comm="mkswap" name="block" dev="tmpfs" ino=9947 scontext=u:r:toolbox:s0 tcontext=u:object_r:block_device:s0 tclass=dir permissive=0 Change-Id: I0c897540f1c7950738622a013121a050a1f32b2f
2014-12-20 02:21:52 +01:00
allow toolbox block_device:dir search;
Do not allow init to execute anything without changing domains. Remove the ability of init to execute programs from / or /system without changing domains. This forces all helper programs and services invoked by init to be assigned their own domain. Introduce separate domains for running the helper programs executed from the fs_mgr library by init. This requires a domain for e2fsck (named fsck for generality) and a domain for running mkswap (named toolbox since mkswap is just a symlink to the toolbox binary and the domain transition occurs on executing the binary, not based on the symlink in any way). e2fsck is invoked on any partitions marked with the check mount option in the fstab file, typically userdata and cache but never system. We allow it to read/write the userdata_block_device and cache_block_device types but also allow it to read/write the default block_device type until we can get the more specific types assigned in all of the device-specific policies. mkswap is invoked on any swap partition defined in the fstab file. We introduce a new swap_block_device type for this purpose, to be assigned to any such block devices in the device-specific policies, and only allow it to read/write such block devices. As there seem to be no devices in AOSP with swap partitions in their fstab files, this does not appear to risk any breakage for existing devices. With the introduction of these domains, we can de-privilege init to only having read access to block devices for mounting filesystems; it no longer needs direct write access to such devices AFAICT. To avoid breaking execution of toolbox by system services, apps, or the shell, we allow all domains other than kernel and init the ability to run toolbox in their own domain. This is broader than strictly required; we could alternatively only add it to those domains that already had x_file_perms to system_file but this would require a coordinated change with device-specific policy. Change-Id: Ib05de2d2bc2781dad48b70ba385577cb855708e4 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
2014-09-23 15:11:30 +02:00
allow toolbox swap_block_device:blk_file rw_file_perms;
# Only allow entry from init via the toolbox binary.
neverallow { domain -init } toolbox:process transition;
Replace "neverallow domain" by "neverallow *" Modify many "neverallow domain" rules to be "neverallow *" rules instead. This will catch more SELinux policy bugs where a label is assigned an irrelevant rule, as well as catch situations where a domain attribute is not assigned to a process. Change-Id: I5b83a2504c13b384f9dff616a70ca733b648ccdf
2016-02-05 23:48:03 +01:00
neverallow * toolbox:process dyntransition;
Do not allow init to execute anything without changing domains. Remove the ability of init to execute programs from / or /system without changing domains. This forces all helper programs and services invoked by init to be assigned their own domain. Introduce separate domains for running the helper programs executed from the fs_mgr library by init. This requires a domain for e2fsck (named fsck for generality) and a domain for running mkswap (named toolbox since mkswap is just a symlink to the toolbox binary and the domain transition occurs on executing the binary, not based on the symlink in any way). e2fsck is invoked on any partitions marked with the check mount option in the fstab file, typically userdata and cache but never system. We allow it to read/write the userdata_block_device and cache_block_device types but also allow it to read/write the default block_device type until we can get the more specific types assigned in all of the device-specific policies. mkswap is invoked on any swap partition defined in the fstab file. We introduce a new swap_block_device type for this purpose, to be assigned to any such block devices in the device-specific policies, and only allow it to read/write such block devices. As there seem to be no devices in AOSP with swap partitions in their fstab files, this does not appear to risk any breakage for existing devices. With the introduction of these domains, we can de-privilege init to only having read access to block devices for mounting filesystems; it no longer needs direct write access to such devices AFAICT. To avoid breaking execution of toolbox by system services, apps, or the shell, we allow all domains other than kernel and init the ability to run toolbox in their own domain. This is broader than strictly required; we could alternatively only add it to those domains that already had x_file_perms to system_file but this would require a coordinated change with device-specific policy. Change-Id: Ib05de2d2bc2781dad48b70ba385577cb855708e4 Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
2014-09-23 15:11:30 +02:00
neverallow toolbox { file_type fs_type -toolbox_exec}:file entrypoint;
Allow toolbox to rm -rf /data/per_boot Bug: 140882488 Test: create files and dirs in /data/per_boot, check they're removed. Change-Id: Idf0ba09cbe51cbff6a7b2a464c4651a1f7fcf343
2019-09-16 19:00:52 +02:00
Restrict creating per-user encrypted directories Creating a per-user encrypted directory such as /data/system_ce/0 and the subdirectories in it too early has been a recurring bug. Typically, individual services in system_server are to blame; system_server has permission to create these directories, and it's easy to write "mkdirs()" instead of "mkdir()". Such bugs are very bad, as they prevent these directories from being encrypted, as encryption policies can only be set on empty directories. Due to recent changes, a factory reset is now forced in such cases, which helps detect these bugs; however, it would be much better to prevent them in the first place. This CL locks down the ability to create these directories to just vold and init, or to just vold when possible. This is done by assigning new types to the directories that contain these directories, and then only allowing the needed domains to write to these parent directories. This is similar to what https://r.android.com/1117297 did for /data itself. Three new types are used instead of just one, since these directories had three different types already (system_data_file, media_rw_data_file, vendor_data_file), and this allows the policy to be a bit more precise. A significant limitation is that /data/user/0 is currently being created by init during early boot. Therefore, this CL doesn't help much for /data/user/0, though it helps a lot for the other directories. As the next step, I'll try to eliminate the /data/user/0 quirk. Anyway, this CL is needed regardless of whether we're able to do that. Test: Booted cuttlefish. Ran 'sm partition disk:253,32 private', then created and deleted a user. Used 'ls -lZ' to check the relevant SELinux labels on both internal and adoptable storage. Also did similar tests on raven, with the addition of going through the setup wizard and using an app that creates media files. No relevant SELinux denials seen during any of this. Bug: 156305599 Change-Id: I1fbdd180f56dd2fe4703763936f5850cef8ab0ba
2022-05-05 00:18:02 +02:00
# rm -rf /data/per_boot
Allow toolbox to rm -rf /data/per_boot Bug: 140882488 Test: create files and dirs in /data/per_boot, check they're removed. Change-Id: Idf0ba09cbe51cbff6a7b2a464c4651a1f7fcf343
2019-09-16 19:00:52 +02:00
allow toolbox system_data_root_file:dir { remove_name write };
allow toolbox system_data_file:dir { rmdir rw_dir_perms };
allow toolbox system_data_file:file { getattr unlink };
Add permissions for chattr This allows init to call chattr to allow casefolding on /data/media Test: lsattr on /data/media on device with casefolding support Bug: 138322712 Change-Id: I5715484d872088517f67c62a78344a2d417dd77f
2020-01-30 00:08:18 +01:00
toolbox.te: remove unneeded FS_IOC_FS[GS]ETXATTR permission These ioctls don't need to be allowed, as they'd only be needed to set project quota IDs. But this is only done by other domains (installd, vold, and mediaprovider_app). Probably it was originally planned for an init script to run 'chattr -p ID', but this didn't end up happening. This is a basically revert of commit 4de3228c461d ("Allow toolbox to set project quota IDs.") (https://r.android.com/1224007). Also remove an outdated comment at the top of the file. Test: booted Cuttlefish, no denials seen. Change-Id: If61179a35f419c6cbfcf1432a86b2c1375db71ed
2022-04-27 02:16:04 +02:00
# chattr +F /data/media in init
Restrict creating per-user encrypted directories Creating a per-user encrypted directory such as /data/system_ce/0 and the subdirectories in it too early has been a recurring bug. Typically, individual services in system_server are to blame; system_server has permission to create these directories, and it's easy to write "mkdirs()" instead of "mkdir()". Such bugs are very bad, as they prevent these directories from being encrypted, as encryption policies can only be set on empty directories. Due to recent changes, a factory reset is now forced in such cases, which helps detect these bugs; however, it would be much better to prevent them in the first place. This CL locks down the ability to create these directories to just vold and init, or to just vold when possible. This is done by assigning new types to the directories that contain these directories, and then only allowing the needed domains to write to these parent directories. This is similar to what https://r.android.com/1117297 did for /data itself. Three new types are used instead of just one, since these directories had three different types already (system_data_file, media_rw_data_file, vendor_data_file), and this allows the policy to be a bit more precise. A significant limitation is that /data/user/0 is currently being created by init during early boot. Therefore, this CL doesn't help much for /data/user/0, though it helps a lot for the other directories. As the next step, I'll try to eliminate the /data/user/0 quirk. Anyway, this CL is needed regardless of whether we're able to do that. Test: Booted cuttlefish. Ran 'sm partition disk:253,32 private', then created and deleted a user. Used 'ls -lZ' to check the relevant SELinux labels on both internal and adoptable storage. Also did similar tests on raven, with the addition of going through the setup wizard and using an app that creates media files. No relevant SELinux denials seen during any of this. Bug: 156305599 Change-Id: I1fbdd180f56dd2fe4703763936f5850cef8ab0ba
2022-05-05 00:18:02 +02:00
allow toolbox media_userdir_file:dir { r_dir_perms setattr };
allowxperm toolbox media_userdir_file:dir ioctl { FS_IOC_SETFLAGS FS_IOC_GETFLAGS };
Reference in a new issue Copy permalink