platform_system_sepolicy/private/vold.te

97 lines
2.6 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);
# 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;
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
# 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
};
# 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
};