platform_system_sepolicy/private/vold.te

480 lines
15 KiB
Text
Raw Normal View History

typeattribute vold coredomain;
init_daemon_domain(vold)
# Switch to more restrictive domains when executing common tools
domain_auto_trans(vold, sgdisk_exec, sgdisk);
domain_auto_trans(vold, sdcardd_exec, sdcardd);
domain_auto_trans(vold, fuseblkd_untrusted_exec, fuseblkd_untrusted);
# Switch to e2fs domain when running mkfs.ext4 to format a partition
domain_auto_trans(vold, e2fs_exec, e2fs);
# For a handful of probing tools, we choose an even more restrictive
# domain when working with untrusted block devices
domain_trans(vold, blkid_exec, blkid);
domain_trans(vold, blkid_exec, blkid_untrusted);
domain_trans(vold, fsck_exec, fsck);
domain_trans(vold, fsck_exec, fsck_untrusted);
# Newly created storage dirs are always treated as mount stubs to prevent us
# from accidentally writing when the mount point isn't present.
type_transition vold storage_file:dir storage_stub_file;
type_transition vold mnt_media_rw_file:dir mnt_media_rw_stub_file;
# Property Service
get_prop(vold, vold_config_prop)
get_prop(vold, storage_config_prop);
get_prop(vold, incremental_prop);
get_prop(vold, gsid_prop);
set_prop(vold, vold_prop)
set_prop(vold, vold_status_prop)
set_prop(vold, powerctl_prop)
set_prop(vold, ctl_fuse_prop)
set_prop(vold, restorecon_prop)
set_prop(vold, ota_prop)
set_prop(vold, boottime_prop)
set_prop(vold, boottime_public_prop)
# Vold will use Keystore instead of using Keymint directly. But it still needs
# to manage its Keymint blobs. This is why it needs the `manage_blob` permission.
allow vold vold_key:keystore2_key {
convert_storage_key_to_ephemeral
delete
get_info
manage_blob
rebind
req_forced_op
update
use
};
# vold needs to call keystore methods
allow vold keystore:binder call;
# vold needs to find keystore2 services
allow vold keystore_service:service_manager find;
allow vold keystore_maintenance_service:service_manager find;
# vold needs to be able to call earlyBootEnded() and deleteAllKeys()
allow vold keystore:keystore2 early_boot_ended;
allow vold keystore:keystore2 delete_all_keys;
Add SELinux policy for storage areas We are adding the ability for apps to create "storage areas", which are transparently encrypted directories that can only be opened when the device is unlocked. This CL makes the required SELinux policy changes. First, assign the type "system_userdir_file" to the new top-level directory /data/storage_area (non-recursively). This is the same type used by the other top-level directories containing app data, such as /data/user, and it restricts access to the directory in the desired way. Second, add new types to represent an app's directory of storage areas, the storage areas themselves, and their contents: `storage_area_app_dir`, `storage_area_dir`, and `storage_area_content_file` respectively. All are `app_data_file_type`s. The directory structure and their associated labels is as follows (note that they also all get the categories of the user+package): /data/storage_area/userId/pkgName storage_area_app_dir /data/storage_area/userId/pkgName/storageAreaName storage_area_dir /data/storage_area/userId/pkgName/storageAreaName/myFile.txt storage_area_content_file /data/storage_area/userId/pkgName/storageAreaName/mySubDir storage_area_content_file These new types allow us to restrict how and which processes interact with storage areas. The new type for the contents of storage areas allows us to add new, desirable restrictions that we cannot add to the more general `app_data_file` type in order to maintain backwards-compatibility, e.g., we block apps from executing any files in their storage areas. Third, allow: -- vold_prepare_subdirs to create and delete storage areas on behalf of apps, and assign them the SElinux type `storage_area_dir` i.e. create directories /data/storage_area/$userId/$pkgName/$storageAreaName -- vold to assign encryption policies to storage area directories -- installd to create an app's directory of storage areas on app install, and delete them on app uninstall, and assign them the SElinux type `storage_area_app_dir`, i.e. directories /data/storage_area/$userId/$pkgName We also add a new SELinux type to represent the storage area encryption keys: `storage_area_key_file`. The keys are created by vold on storage area creation, and deleted either by vold if an app calls the `deleteStorageArea` API function explicitly, or by installd on app uninstall. These keys are stored in `/data/misc_ce/$userId/storage_area_keys`, and only installd and vold have access to them. Bug: 325121608 Test: atest StorageAreaTest Change-Id: I74805d249f59226fc6963693f682c70949bfad93
2024-04-30 22:26:55 +02:00
is_flag_enabled(RELEASE_UNLOCKED_STORAGE_API, `
# Allow vold to encrypt storage area directories on behalf of apps.
allow vold {
storage_area_dir
storage_area_app_dir
}:dir {
getattr
ioctl # for FS_IOC_SET_ENCRYPTION_POLICY
open
read # for open(O_RDONLY) for ioctl
search
};
')
# when a storage area is created (with `openStorageArea`), vold creates the key
# and when a storage area is deleted (with `deleteStorageArea`), vold deletes the key
is_flag_enabled(RELEASE_UNLOCKED_STORAGE_API, `
allow vold storage_area_key_file:file create_file_perms;
allow vold storage_area_key_file:dir create_dir_perms;
')
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 vold to create and delete per-user directories like /data/user/$userId.
allow vold {
media_userdir_file
system_userdir_file
vendor_userdir_file
}:dir {
add_name
remove_name
write
};
# Read already opened /cache files.
allow vold cache_file:dir r_dir_perms;
allow vold cache_file:file { getattr read };
allow vold cache_file:lnk_file r_file_perms;
r_dir_file(vold, { sysfs_type -sysfs_batteryinfo })
# XXX Label sysfs files with a specific type?
allow vold {
sysfs # writing to /sys/*/uevent during coldboot.
sysfs_devices_block
sysfs_dm
sysfs_loop # writing to /sys/block/loop*/uevent during coldboot.
sysfs_usb
sysfs_zram_uevent
sysfs_fs_f2fs
}:file w_file_perms;
r_dir_file(vold, rootfs)
r_dir_file(vold, metadata_file)
allow vold {
proc # b/67049235 processes /proc/<pid>/* files are mislabeled.
proc_bootconfig
proc_cmdline
proc_drop_caches
proc_filesystems
proc_meminfo
proc_mounts
}:file r_file_perms;
#Get file contexts
allow vold file_contexts_file:file r_file_perms;
# Allow us to jump into execution domains of above tools
allow vold self:process setexec;
# For formatting adoptable storage devices
allow vold e2fs_exec:file rx_file_perms;
# Run fstrim on mounted partitions
# allowxperm still requires the ioctl permission for the individual type
allowxperm vold { fs_type file_type }:dir ioctl FITRIM;
# Get/set file-based encryption policies on dirs in /data and adoptable storage,
# and add/remove file-based encryption keys.
allowxperm vold data_file_type:dir ioctl {
FS_IOC_GET_ENCRYPTION_POLICY
Add SELinux policy for storage areas We are adding the ability for apps to create "storage areas", which are transparently encrypted directories that can only be opened when the device is unlocked. This CL makes the required SELinux policy changes. First, assign the type "system_userdir_file" to the new top-level directory /data/storage_area (non-recursively). This is the same type used by the other top-level directories containing app data, such as /data/user, and it restricts access to the directory in the desired way. Second, add new types to represent an app's directory of storage areas, the storage areas themselves, and their contents: `storage_area_app_dir`, `storage_area_dir`, and `storage_area_content_file` respectively. All are `app_data_file_type`s. The directory structure and their associated labels is as follows (note that they also all get the categories of the user+package): /data/storage_area/userId/pkgName storage_area_app_dir /data/storage_area/userId/pkgName/storageAreaName storage_area_dir /data/storage_area/userId/pkgName/storageAreaName/myFile.txt storage_area_content_file /data/storage_area/userId/pkgName/storageAreaName/mySubDir storage_area_content_file These new types allow us to restrict how and which processes interact with storage areas. The new type for the contents of storage areas allows us to add new, desirable restrictions that we cannot add to the more general `app_data_file` type in order to maintain backwards-compatibility, e.g., we block apps from executing any files in their storage areas. Third, allow: -- vold_prepare_subdirs to create and delete storage areas on behalf of apps, and assign them the SElinux type `storage_area_dir` i.e. create directories /data/storage_area/$userId/$pkgName/$storageAreaName -- vold to assign encryption policies to storage area directories -- installd to create an app's directory of storage areas on app install, and delete them on app uninstall, and assign them the SElinux type `storage_area_app_dir`, i.e. directories /data/storage_area/$userId/$pkgName We also add a new SELinux type to represent the storage area encryption keys: `storage_area_key_file`. The keys are created by vold on storage area creation, and deleted either by vold if an app calls the `deleteStorageArea` API function explicitly, or by installd on app uninstall. These keys are stored in `/data/misc_ce/$userId/storage_area_keys`, and only installd and vold have access to them. Bug: 325121608 Test: atest StorageAreaTest Change-Id: I74805d249f59226fc6963693f682c70949bfad93
2024-04-30 22:26:55 +02:00
FS_IOC_GET_ENCRYPTION_POLICY_EX
FS_IOC_SET_ENCRYPTION_POLICY
FS_IOC_ADD_ENCRYPTION_KEY
FS_IOC_REMOVE_ENCRYPTION_KEY
FS_IOC_GET_ENCRYPTION_KEY_STATUS
};
# Allow securely erasing crypto key files. F2FS_IOC_SEC_TRIM_FILE is
# tried first. Otherwise, FS_IOC_FIEMAP is needed to get the
# location of the file's blocks on the raw block device to erase.
allowxperm vold {
vold_data_file
vold_metadata_file
Add SELinux policy for storage areas We are adding the ability for apps to create "storage areas", which are transparently encrypted directories that can only be opened when the device is unlocked. This CL makes the required SELinux policy changes. First, assign the type "system_userdir_file" to the new top-level directory /data/storage_area (non-recursively). This is the same type used by the other top-level directories containing app data, such as /data/user, and it restricts access to the directory in the desired way. Second, add new types to represent an app's directory of storage areas, the storage areas themselves, and their contents: `storage_area_app_dir`, `storage_area_dir`, and `storage_area_content_file` respectively. All are `app_data_file_type`s. The directory structure and their associated labels is as follows (note that they also all get the categories of the user+package): /data/storage_area/userId/pkgName storage_area_app_dir /data/storage_area/userId/pkgName/storageAreaName storage_area_dir /data/storage_area/userId/pkgName/storageAreaName/myFile.txt storage_area_content_file /data/storage_area/userId/pkgName/storageAreaName/mySubDir storage_area_content_file These new types allow us to restrict how and which processes interact with storage areas. The new type for the contents of storage areas allows us to add new, desirable restrictions that we cannot add to the more general `app_data_file` type in order to maintain backwards-compatibility, e.g., we block apps from executing any files in their storage areas. Third, allow: -- vold_prepare_subdirs to create and delete storage areas on behalf of apps, and assign them the SElinux type `storage_area_dir` i.e. create directories /data/storage_area/$userId/$pkgName/$storageAreaName -- vold to assign encryption policies to storage area directories -- installd to create an app's directory of storage areas on app install, and delete them on app uninstall, and assign them the SElinux type `storage_area_app_dir`, i.e. directories /data/storage_area/$userId/$pkgName We also add a new SELinux type to represent the storage area encryption keys: `storage_area_key_file`. The keys are created by vold on storage area creation, and deleted either by vold if an app calls the `deleteStorageArea` API function explicitly, or by installd on app uninstall. These keys are stored in `/data/misc_ce/$userId/storage_area_keys`, and only installd and vold have access to them. Bug: 325121608 Test: atest StorageAreaTest Change-Id: I74805d249f59226fc6963693f682c70949bfad93
2024-04-30 22:26:55 +02:00
is_flag_enabled(RELEASE_UNLOCKED_STORAGE_API, `storage_area_key_file')
}:file ioctl {
F2FS_IOC_SEC_TRIM_FILE
FS_IOC_FIEMAP
};
typeattribute vold mlstrustedsubject;
allow vold self:process setfscreate;
allow vold system_file:file x_file_perms;
not_full_treble(`allow vold vendor_file:file x_file_perms;')
allow vold block_device:dir create_dir_perms;
allow vold device:dir write;
allow vold devpts:chr_file rw_file_perms;
allow vold rootfs:dir mounton;
allow vold { sdcard_type fuse }:dir mounton; # TODO: deprecated in M
allow vold { sdcard_type fuse }:filesystem { mount remount unmount }; # TODO: deprecated in M
# Manage locations where storage is mounted
allow vold { mnt_media_rw_file storage_file sdcard_type fuse }:dir create_dir_perms;
allow vold { mnt_media_rw_file storage_file sdcard_type fuse }:file create_file_perms;
# Access to storage that backs emulated FUSE daemons for migration optimization
allow vold media_rw_data_file:dir create_dir_perms;
allow vold media_rw_data_file:file create_file_perms;
# Allow mounting (lower filesystem) on parts of media for performance
allow vold media_rw_data_file:dir mounton;
# Allow setting project quota IDs and enabling project ID inheritance on
# /data/media/$userId/* and /mnt/expand/$volume/media/$userId/*
allowxperm vold media_rw_data_file:{ dir file } ioctl {
FS_IOC_FSGETXATTR
FS_IOC_FSSETXATTR
FS_IOC_GETFLAGS
FS_IOC_SETFLAGS
};
# Allow mounting of storage devices
allow vold { mnt_media_rw_stub_file storage_stub_file }:dir { mounton create rmdir getattr setattr };
# Manage per-user primary symlinks
allow vold mnt_user_file:dir { create_dir_perms mounton };
allow vold mnt_user_file:lnk_file create_file_perms;
allow vold mnt_user_file:file create_file_perms;
# Manage per-user pass_through primary symlinks
allow vold mnt_pass_through_file:dir { create_dir_perms mounton };
allow vold mnt_pass_through_file:lnk_file create_file_perms;
# Allow to create and mount expanded storage
allow vold mnt_expand_file:dir { create_dir_perms mounton };
allow vold apk_data_file:dir { create getattr setattr };
allow vold shell_data_file:dir { create getattr setattr };
allow vold system_userdir_file:dir { create getattr setattr };
allow vold media_userdir_file:dir { create getattr setattr open read ioctl };
# Needed to set the casefold flag on /mnt/expand/$volume/media
allowxperm vold media_userdir_file:dir ioctl { FS_IOC_GETFLAGS FS_IOC_SETFLAGS };
# Allow to mount incremental file system on /data/incremental and create files
allow vold apk_data_file:dir { mounton rw_dir_perms };
# Allow to create and write files in /data/incremental
allow vold apk_data_file:file { rw_file_perms unlink };
# Allow to bind-mount incremental file system on /data/app/vmdl*.tmp and read files
allow vold apk_tmp_file:dir { mounton r_dir_perms };
# Allow to read incremental control file and call selinux restorecon on it
allow vold incremental_control_file:file { r_file_perms relabelto };
allow vold tmpfs:filesystem { mount unmount };
allow vold tmpfs:dir create_dir_perms;
allow vold tmpfs:dir mounton;
allow vold self:global_capability_class_set { net_admin dac_override dac_read_search mknod sys_admin chown fowner fsetid };
allow vold self:netlink_kobject_uevent_socket create_socket_perms_no_ioctl;
allow vold loop_control_device:chr_file rw_file_perms;
allow vold loop_device:blk_file { create setattr unlink rw_file_perms };
allowxperm vold loop_device:blk_file ioctl {
LOOP_CLR_FD
LOOP_CTL_GET_FREE
LOOP_GET_STATUS64
LOOP_SET_FD
LOOP_SET_STATUS64
};
allow vold vold_device:blk_file { create setattr unlink rw_file_perms };
allowxperm vold vold_device:blk_file ioctl { BLKDISCARD BLKGETSIZE };
allow vold dm_device:chr_file rw_file_perms;
allow vold dm_device:blk_file rw_file_perms;
allowxperm vold dm_device:blk_file ioctl { BLKDISCARD BLKSECDISCARD BLKREPORTZONE BLKRESETZONE };
# For vold Process::killProcessesWithOpenFiles function.
allow vold domain:dir r_dir_perms;
allow vold domain:{ file lnk_file } r_file_perms;
allow vold domain:process { signal sigkill };
allow vold self:global_capability_class_set { sys_ptrace kill };
allow vold kmsg_device:chr_file rw_file_perms;
# Run fsck in the fsck domain.
allow vold fsck_exec:file { r_file_perms execute };
# Log fsck results
allow vold fscklogs:dir rw_dir_perms;
allow vold fscklogs:file create_file_perms;
# Mount and unmount filesystems.
allow vold labeledfs:filesystem { mount unmount remount };
# Create and mount on /data/tmp_mnt and management of expansion mounts
#
# Also rename per-user encrypted directories such as /data/user/10 from their
# temporary name ("10.new") to their final name ("10").
allow vold {
system_data_file
system_data_root_file
}:dir { create_dir_perms mounton };
allow vold system_data_file:lnk_file getattr;
# Vold create users in /data/vendor_{ce,de}/[0-9]+
allow vold vendor_data_file:dir create_dir_perms;
# for secdiscard
allow vold system_data_file:file read;
# Set scheduling policy of kernel processes
allow vold kernel:process setsched;
# ASEC
allow vold asec_image_file:file create_file_perms;
allow vold asec_image_file:dir rw_dir_perms;
allow vold asec_apk_file:dir { create_dir_perms mounton relabelfrom relabelto };
allow vold asec_public_file:dir { relabelto setattr };
allow vold asec_apk_file:file { r_file_perms setattr relabelfrom relabelto };
allow vold asec_public_file:file { relabelto setattr };
# restorecon files in asec containers created on 4.2 or earlier.
allow vold unlabeled:dir { r_dir_perms setattr relabelfrom };
allow vold unlabeled:file { r_file_perms setattr relabelfrom };
# Access to FUSE control filesystem to hard-abort FUSE mounts
allow vold fusectlfs:file rw_file_perms;
allow vold fusectlfs:dir rw_dir_perms;
# Allow vold to use wake locks. Needed for idle maintenance and moving storage.
wakelock_use(vold)
# Allow vold to publish a binder service and make binder calls.
binder_use(vold)
add_service(vold, vold_service)
# Allow vold to call into the system server so it can check permissions.
binder_call(vold, system_server)
allow vold permission_service:service_manager find;
# talk to health storage HAL
hal_client_domain(vold, hal_health_storage)
# talk to bootloader HAL
full_treble_only(`hal_client_domain(vold, hal_bootctl)')
# Access userdata block device.
allow vold userdata_block_device:blk_file rw_file_perms;
allowxperm vold userdata_block_device:blk_file ioctl BLKSECDISCARD;
# Access zoned block device.
allow vold zoned_block_device:blk_file rw_file_perms;
# Access metadata block device used for encryption meta-data.
allow vold metadata_block_device:blk_file rw_file_perms;
allowxperm vold metadata_block_device:blk_file ioctl BLKSECDISCARD;
# Allow vold to manipulate /data/unencrypted
allow vold unencrypted_data_file:{ file } create_file_perms;
allow vold unencrypted_data_file:dir create_dir_perms;
# Write to /proc/sys/vm/drop_caches
allow vold proc_drop_caches:file w_file_perms;
# Give vold a place where only vold can store files; everyone else is off limits
allow vold vold_data_file:dir create_dir_perms;
allow vold vold_data_file:file create_file_perms;
# And a similar place in the metadata partition
allow vold vold_metadata_file:dir create_dir_perms;
allow vold vold_metadata_file:file create_file_perms;
# linux keyring configuration
allow vold init:key { write search setattr };
allow vold vold:key { write search setattr };
# vold temporarily changes its priority when running benchmarks
allow vold self:global_capability_class_set sys_nice;
# vold needs to chroot into app namespaces to remount when runtime permissions change
allow vold self:global_capability_class_set sys_chroot;
allow vold storage_file:dir mounton;
# For AppFuse.
allow vold fuse_device:chr_file rw_file_perms;
allow vold fuse:filesystem { relabelfrom };
allow vold app_fusefs:filesystem { relabelfrom relabelto };
allow vold app_fusefs:filesystem { mount unmount };
allow vold app_fuse_file:dir rw_dir_perms;
allow vold app_fuse_file:file { read write open getattr append };
# MoveStorage.cpp executes cp and rm
allow vold toolbox_exec:file rx_file_perms;
# Prepare profile dir for users.
allow vold { user_profile_data_file user_profile_root_file }:dir create_dir_perms;
# Raw writes to misc block device
allow vold misc_block_device:blk_file w_file_perms;
# vold might need to search or mount /mnt/vendor/*
allow vold mnt_vendor_file:dir search;
dontaudit vold self:global_capability_class_set sys_resource;
# Allow ReadDefaultFstab().
read_fstab(vold)
# vold might need to search loopback apex files
allow vold vendor_apex_file:file r_file_perms;
###
### Neverallow rules
###
neverallow {
domain
-system_server
-vdc
-vold
-update_verifier
-apexd
-gsid
} vold_service:service_manager find;
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
# Only vold should create (and delete) per-user directories like
# /data/user/$userId. This is very important, as these directories need to be
# encrypted with per-user keys, which only vold can do. Encryption can only be
# set up on empty directories, so creation and encryption must happen together.
neverallow {
domain
-vold
} {
media_userdir_file
system_userdir_file
vendor_userdir_file
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
}:dir {
add_name
remove_name
write
};
# Only vold and init should ever set file-based encryption policies.
neverallowxperm {
domain
-vold
-init
-vendor_init
} data_file_type:dir ioctl { FS_IOC_SET_ENCRYPTION_POLICY };
# Only vold should ever add/remove file-based encryption keys.
neverallowxperm {
domain
-vold
} data_file_type:dir ioctl { FS_IOC_ADD_ENCRYPTION_KEY FS_IOC_REMOVE_ENCRYPTION_KEY FS_IOC_GET_ENCRYPTION_KEY_STATUS };
neverallow {
domain
-vold
-vold_prepare_subdirs
} vold_data_file:dir ~{ open create read getattr setattr search relabelfrom relabelto ioctl };
neverallow {
domain
-init
-vold
-vold_prepare_subdirs
} vold_data_file:dir *;
neverallow {
domain
-init
-vold
} vold_metadata_file:dir *;
neverallow {
domain
-kernel
-vold
-vold_prepare_subdirs
} vold_data_file:notdevfile_class_set ~{ relabelto getattr };
neverallow {
domain
-init
-vold
-vold_prepare_subdirs
} vold_metadata_file:notdevfile_class_set ~{ relabelto getattr };
neverallow {
domain
-init
-kernel
-vold
-vold_prepare_subdirs
} { vold_data_file vold_metadata_file }:notdevfile_class_set *;
neverallow { domain -vold -init } restorecon_prop:property_service set;
neverallow vold {
domain
-hal_health_storage_server
-hal_keymaster_server
-system_suspend_server
-hal_bootctl_server
-hwservicemanager
-keystore
-servicemanager
-system_server
userdebug_or_eng(`-su')
}:binder call;
neverallow vold fsck_exec:file execute_no_trans;
neverallow { domain -init } vold:process { transition dyntransition };
neverallow vold *:process ptrace;
neverallow vold *:rawip_socket *;