2017-10-13 23:54:32 +02:00
|
|
|
domain_auto_trans(vold, vold_prepare_subdirs_exec, vold_prepare_subdirs)
|
2017-10-19 23:41:37 +02:00
|
|
|
|
2024-03-27 09:18:41 +01:00
|
|
|
typeattribute vold_prepare_subdirs coredomain;
|
2020-02-11 15:43:05 +01:00
|
|
|
typeattribute vold_prepare_subdirs mlstrustedsubject;
|
|
|
|
|
|
2017-10-25 22:03:24 +02:00
|
|
|
allow vold_prepare_subdirs system_file:file execute_no_trans;
|
|
|
|
|
allow vold_prepare_subdirs shell_exec:file rx_file_perms;
|
|
|
|
|
allow vold_prepare_subdirs toolbox_exec:file rx_file_perms;
|
|
|
|
|
allow vold_prepare_subdirs devpts:chr_file rw_file_perms;
|
|
|
|
|
allow vold_prepare_subdirs vold:fd use;
|
|
|
|
|
allow vold_prepare_subdirs vold:fifo_file { read write };
|
|
|
|
|
allow vold_prepare_subdirs file_contexts_file:file r_file_perms;
|
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
|
|
|
allow vold_prepare_subdirs seapp_contexts_file:file r_file_perms;
|
2018-09-07 00:19:40 +02:00
|
|
|
allow vold_prepare_subdirs self:global_capability_class_set { chown dac_override dac_read_search fowner };
|
2017-10-25 22:03:24 +02:00
|
|
|
allow vold_prepare_subdirs self:process setfscreate;
|
2018-02-08 01:29:06 +01:00
|
|
|
allow vold_prepare_subdirs {
|
2022-05-11 22:43:54 +02:00
|
|
|
sdk_sandbox_system_data_file
|
2018-02-08 01:29:06 +01:00
|
|
|
system_data_file
|
|
|
|
|
vendor_data_file
|
2018-04-16 23:50:38 +02:00
|
|
|
}:dir { open read write add_name remove_name rmdir relabelfrom };
|
2018-04-26 22:41:13 +02:00
|
|
|
allow vold_prepare_subdirs {
|
2021-07-12 15:21:48 +02:00
|
|
|
apex_data_file_type
|
2019-11-19 19:10:16 +01:00
|
|
|
apex_module_data_file
|
2019-12-02 19:29:48 +01:00
|
|
|
apex_rollback_data_file
|
2019-01-15 22:20:13 +01:00
|
|
|
backup_data_file
|
2021-10-06 07:13:20 +02:00
|
|
|
checkin_data_file
|
2018-11-16 00:28:07 +01:00
|
|
|
face_vendor_data_file
|
2018-11-19 19:42:11 +01:00
|
|
|
fingerprint_vendor_data_file
|
2018-11-16 00:28:07 +01:00
|
|
|
iris_vendor_data_file
|
2019-01-14 16:02:12 +01:00
|
|
|
rollback_data_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')
|
2018-04-26 22:41:13 +02:00
|
|
|
storaged_data_file
|
2022-02-21 18:55:59 +01:00
|
|
|
sdk_sandbox_data_file
|
2022-05-11 22:43:54 +02:00
|
|
|
sdk_sandbox_system_data_file
|
2020-02-11 15:43:05 +01:00
|
|
|
system_data_file
|
2018-04-26 22:41:13 +02:00
|
|
|
vold_data_file
|
|
|
|
|
}:dir { create_dir_perms relabelto };
|
|
|
|
|
allow vold_prepare_subdirs {
|
2021-07-12 15:21:48 +02:00
|
|
|
apex_data_file_type
|
2020-10-16 16:29:55 +02:00
|
|
|
apex_art_staging_data_file
|
2019-11-19 19:10:16 +01:00
|
|
|
apex_module_data_file
|
2019-12-02 19:29:48 +01:00
|
|
|
apex_rollback_data_file
|
2019-01-15 22:20:13 +01:00
|
|
|
backup_data_file
|
2021-10-06 07:13:20 +02:00
|
|
|
checkin_data_file
|
2018-11-16 00:28:07 +01:00
|
|
|
face_vendor_data_file
|
2018-11-19 19:42:11 +01:00
|
|
|
fingerprint_vendor_data_file
|
2018-11-16 00:28:07 +01:00
|
|
|
iris_vendor_data_file
|
2019-01-14 16:02:12 +01:00
|
|
|
rollback_data_file
|
2018-04-26 22:41:13 +02:00
|
|
|
storaged_data_file
|
2022-02-21 18:55:59 +01:00
|
|
|
sdk_sandbox_data_file
|
2018-04-26 22:41:13 +02:00
|
|
|
system_data_file
|
|
|
|
|
vold_data_file
|
|
|
|
|
}:file { getattr unlink };
|
2019-11-19 19:10:16 +01:00
|
|
|
allow vold_prepare_subdirs apex_mnt_dir:dir { open read };
|
2020-02-11 15:43:05 +01:00
|
|
|
allow vold_prepare_subdirs mnt_expand_file:dir search;
|
2020-12-04 15:07:52 +01:00
|
|
|
allow vold_prepare_subdirs user_profile_data_file:dir { search getattr relabelfrom };
|
|
|
|
|
allow vold_prepare_subdirs user_profile_root_file:dir { search getattr relabelfrom relabelto };
|
2022-02-08 16:44:06 +01:00
|
|
|
|
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
|
|
|
# Allow vold_prepare_subdirs to create storage area directories on behalf of apps.
|
|
|
|
|
is_flag_enabled(RELEASE_UNLOCKED_STORAGE_API, `
|
|
|
|
|
allow vold_prepare_subdirs {
|
|
|
|
|
storage_area_dir
|
|
|
|
|
storage_area_app_dir
|
|
|
|
|
}:dir {
|
|
|
|
|
rw_dir_perms
|
|
|
|
|
create
|
|
|
|
|
setattr # for chown() and chmod()
|
|
|
|
|
rmdir
|
|
|
|
|
unlink
|
|
|
|
|
relabelfrom # setfilecon
|
|
|
|
|
relabelto # setfilecon
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
# The storage area directories should have type storage_area_dir
|
|
|
|
|
type_transition vold_prepare_subdirs storage_area_app_dir:dir storage_area_dir;
|
|
|
|
|
|
|
|
|
|
selinux_check_context(vold_prepare_subdirs)
|
2024-05-20 19:59:16 +02:00
|
|
|
|
|
|
|
|
allowxperm vold_prepare_subdirs storage_area_dir:dir ioctl FS_IOC_SET_ENCRYPTION_POLICY;
|
|
|
|
|
')
|
|
|
|
|
|
|
|
|
|
is_flag_enabled(RELEASE_UNLOCKED_STORAGE_API, `
|
|
|
|
|
neverallowxperm vold_prepare_subdirs {
|
|
|
|
|
data_file_type
|
|
|
|
|
-storage_area_dir
|
|
|
|
|
}:dir ioctl FS_IOC_SET_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
|
|
|
')
|
|
|
|
|
|
2022-02-08 16:44:06 +01:00
|
|
|
# Migrate legacy labels to apex_system_server_data_file (b/217581286)
|
|
|
|
|
allow vold_prepare_subdirs {
|
|
|
|
|
apex_appsearch_data_file
|
|
|
|
|
apex_permission_data_file
|
|
|
|
|
apex_scheduling_data_file
|
2022-05-03 15:44:35 +02:00
|
|
|
apex_tethering_data_file
|
2022-02-08 16:44:06 +01:00
|
|
|
apex_wifi_data_file
|
|
|
|
|
}:dir relabelfrom;
|
|
|
|
|
|
2020-02-11 15:43:05 +01:00
|
|
|
# /data/misc is unlabeled during early boot.
|
|
|
|
|
allow vold_prepare_subdirs unlabeled:dir search;
|
2019-05-09 19:43:59 +02:00
|
|
|
|
|
|
|
|
dontaudit vold_prepare_subdirs { proc unlabeled }:file r_file_perms;
|
