2017-03-23 22:27:32 +01:00
|
|
|
typeattribute vold coredomain;
|
|
|
|
|
2016-07-22 22:13:11 +02:00
|
|
|
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
|
2018-12-01 00:58:26 +01:00
|
|
|
domain_trans(vold, blkid_exec, blkid);
|
|
|
|
domain_trans(vold, blkid_exec, blkid_untrusted);
|
2016-07-22 22:13:11 +02:00
|
|
|
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;
|
2020-03-04 09:20:35 +01:00
|
|
|
|
|
|
|
# Property Service
|
2020-04-06 13:49:17 +02:00
|
|
|
get_prop(vold, vold_config_prop)
|
2020-04-10 14:11:49 +02:00
|
|
|
get_prop(vold, storage_config_prop);
|
2020-04-28 22:24:54 +02:00
|
|
|
get_prop(vold, incremental_prop);
|
2021-09-16 03:55:50 +02:00
|
|
|
get_prop(vold, gsid_prop);
|
2020-04-06 13:49:17 +02:00
|
|
|
|
2020-03-04 09:20:35 +01:00
|
|
|
set_prop(vold, vold_prop)
|
2020-04-06 13:49:17 +02:00
|
|
|
set_prop(vold, vold_status_prop)
|
2020-03-04 09:20:35 +01:00
|
|
|
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)
|
2020-03-04 09:20:35 +01:00
|
|
|
set_prop(vold, boottime_public_prop)
|
2020-08-01 07:22:49 +02:00
|
|
|
|
|
|
|
# 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 {
|
2021-03-08 18:48:42 +01:00
|
|
|
convert_storage_key_to_ephemeral
|
2020-08-01 07:22:49 +02:00
|
|
|
delete
|
|
|
|
get_info
|
|
|
|
manage_blob
|
|
|
|
rebind
|
|
|
|
req_forced_op
|
|
|
|
update
|
|
|
|
use
|
|
|
|
};
|
2020-08-29 10:45:24 +02:00
|
|
|
|
2021-03-01 11:53:46 +01:00
|
|
|
# vold needs to call keystore methods
|
|
|
|
allow vold keystore:binder call;
|
|
|
|
|
2021-03-11 12:57:03 +01:00
|
|
|
# vold needs to find keystore2 services
|
2021-03-01 11:53:46 +01:00
|
|
|
allow vold keystore_service:service_manager find;
|
2021-03-11 12:57:03 +01:00
|
|
|
allow vold keystore_maintenance_service:service_manager find;
|
|
|
|
|
2021-08-07 00:11:53 +02:00
|
|
|
# vold needs to be able to call earlyBootEnded() and deleteAllKeys()
|
2021-03-11 12:57:03 +01:00
|
|
|
allow vold keystore:keystore2 early_boot_ended;
|
2021-08-07 00:11:53 +02:00
|
|
|
allow vold keystore:keystore2 delete_all_keys;
|
2021-03-11 12:57:03 +01:00
|
|
|
|
2020-10-07 07:59:52 +02:00
|
|
|
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
|
2022-05-11 07:33:07 +02:00
|
|
|
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
|
|
|
|
};
|