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
Ideally, public should only contain APIs (types / attributes) for
vendor. The other statements like allow/neverallow/typeattributes are
regarded as implementation detail for platform and should be in private.
Bug: 232023812
Test: m selinux_policy
Test: diff <(git diff --staged | grep "^-" | cut -b2- | sort) \
<(git diff --staged | grep "^+" | cut -b2- | sort)
Test: remove comments on plat_sepolicy.cil, replace base_typeattr_*
to base_typeattr and then compare old and new plat_sepolicy.cil
Change-Id: I5e7d2da4465ab0216de6bacdf03077d37f6ffe12
to get the list of active APEXes.
Bug: 293949266
Bug: 293546778
Test: CtsPackageSettingHostTestCases
Change-Id: I86f58158b97463206fb76a0c31f29b78874f4c35
Currently, app process can freely execute path at
`/data/misc_ce/0/sdksandbox/<package-name>` since it's labeled as system
file. They can't read or write, but use 403/404
error to figure out if an app is installed or not.
By changing the selinux label of the parent directory:
`/data/misc_ce/0/sdksandbox`, we can restrict app process from executing
inside the directory and avoid the privacy leak.
Sandbox process should only have "search" permission on the new label so
that it can pass through it to its data directory located in
`/data/misc_ce/0/sdksandbox/<package-name>/<per-sdk-dir>`.
Bug: 214241165
Test: atest SdkSandboxStorageHostTest
Test: `adb shell cd /data/misc_ce/0/sdksandbox` gives error
Test: manual test to verify webview still works
Ignore-AOSP-First: Test is missing in AOSP. Will cherry-pick to AOSP
once merged here.
Change-Id: Id8771b322d4eb5532eaf719f203ca94035e2a8ed
When an user is deleted, vold_prepare_subdirs needs to be able to
destroy the subdirs.
Bug: 220114055
Bug: 217543371
Test: atest CtsMultiUserHostTestCases
Ignore-AOSP-First: Feature is being developed in internal branch
Change-Id: I987ce31e648d93e124f1644348f463dd7a406c19
Merged-In: I987ce31e648d93e124f1644348f463dd7a406c19
(cherry picked from commit f4ff1e3a3d)
This partly reverts fa10a14fac. There we
removed individual labels for various apexdata labels, replacing them
with apex_system_server_data_file.
Unfortunately that doesn't handle upgrade scenarios well, e.g. when
updating system but keeping the old vendor sepolicy. The directories
keep their old labels, and vold_prepare_subdirs is unable to relabel
them as there is no policy to allow it to.
So we bring back the legacy labels, in private not public, and add the
rules needed to ensure system_server and vold_prepare_subdirs have the
access they need. All the other access needed is obtained via the
apex_data_file_type attribute.
Bug: 217581286
Test: Reset labels using chcon, reboot, directories are relabeled, no denials
Change-Id: If696882450f2634e382f217dab8f9f3882bff03f
Checkin apps use /data/misc_ce/<id>/checkin to backup the checkin
metadata. So users won't lose the checkin tokens when they clear
the app's storage.
One example is when GMScore is used for checkin, users may clear
GMScore data via "settings". If the device accidentally loses the
token without backup, it won't be able to checkin again until
factory reset.
The contents in checkin dir will be cleaned up when a user is removed
from the device. We also plan to add Gmscore test to ensure the dir
is cleaned up at checkin time, thus prevent other Gmscore modules
from using this storage by mistake.
Bug: 197636740
Test: boot device, check selinux label, check gmscore writes to the new dir
Change-Id: If3ff5e0fb75b4d49ce80d91b0086b58db002e4fb
We ended up with 4 labels for specific APEX files that were all
identical; I've replaced them with a single one
(apex_system_server_data_file).
Additionally I created an attribute to be applied to a "standard" APEX
module data file type that establishes the basics (it can be managed
by vold_prepare_subdirs and apexd), to make it easier to add new such
types - which I'm about to do.
Fix: 189415223
Test: Presubmits
Change-Id: I4406f6680aa8aa0e38afddb2f3ba75f8bfbb8c3c
odrefresh is the process responsible for checking and creating ART
compilation artifacts that live in the ART APEX data
directory (/data/misc/apexdata/com.android.art).
There are two types of change here:
1) enabling odrefresh to run dex2oat and write updated boot class path
and system server AOT artifacts into the ART APEX data directory.
2) enabling the zygote and assorted diagnostic tools to use the
updated AOT artifacts.
odrefresh uses two file contexts: apex_art_data_file and
apex_art_staging_data_file. When odrefresh invokes dex2oat, the
generated files have the apex_art_staging_data_file label (which allows
writing). odrefresh then moves these files from the staging area to
their installation area and gives them the apex_art_data_file label.
Bug: 160683548
Test: adb root && adb shell /apex/com.android.art/bin/odrefresh
Change-Id: I9fa290e0c9c1b7b82be4dacb9f2f8cb8c11e4895
user_profile_data_file is mlstrustedobject. And it needs to be,
because we want untrusted apps to be able to write to their profile
files, but they do not have levels.
But now we want to apply levels in the parent directories that have
the same label, and we want them to work so they need to not be
MLS-exempt. To resolve that we introduce a new label,
user_profile_root_file, which is applied to those directories (but no
files). We grant mostly the same access to the new label as
directories with the existing label.
Apart from appdomain, almost every domain which accesses
user_profile_data_file, and now user_profile_root_file, is already
mlstrustedsubject and so can't be affected by this change. The
exception is postinstall_dexopt which we now make mlstrustedobject.
Bug: 141677108
Bug: 175311045
Test: Manual: flash with wipe
Test: Manual: flash on top of older version
Test: Manual: install & uninstall apps
Test: Manual: create & remove user
Test: Presubmits.
Change-Id: I4e0def3d513b129d6c292f7edb076db341b4a2b3
We want to extend vold_prepare_subdirs to set the MLS level to the
correct per-user value for selected user-specific directories.
Grant vold_prepare_subdirs the access it needs to do this, and allow
vold to access the temporary property controlling this.
Bug: 141677108
Test: Manual, with and without property set.
Change-Id: I572462cfd9b8869381f2af5faa29165bb8373d4b
This adds a new apex_rollback_data_file type for the snapshots (backups)
of APEX data directories that can be restored in the event of a rollback.
Permission is given for apexd to create files and dirs in those directories
and for vold_prepare_subdirs to create the directories.
See go/apex-data-directories for details.
Bug: 141148175
Test: Built and flashed, checked directory was created with the correct
type.
Change-Id: I94b448dfc096e5702d3e33ace6f9df69f58340fd
This adds a new apex_module_data_file type for the APEX data directories
under /data/misc/apexdata and /data/misc_[de|ce]/<u>/apexdata.
Permission is given for vold to identify which APEXes are present and
create the corresponding directories under apexdata in the ce/de user
directories.
See go/apex-data-directories.
Bug: 141148175
Test: Built & flashed, checked directories were created.
Change-Id: I95591e5fe85fc34f7ed21e2f4a75900ec2cfacfa
This reverts commit 3aa1c1725e.
Reason for revert: Wifi services no longer plan to be a separate
APK/process for mainline. Will instead become a jar loaded from Apex.
Bug: 144722612
Test: Device boots up & connects to wifi networks
Change-Id: Ifa33dae971dccfd5d14991727e2f27d2398fdc74
Move wifi services out of system_server into a separate APK/process.
Changes:
a) Created sepolicy for the new wifi apk.
b) The new APK will run with network_stack uid (eventually will be moved
to the same process).
Used 'audit2allow' tool to gather list of permissions required.
Note: The existing wifi related permissions in system_server is left
behind to allow the module to be loaded into system_server or
network_stack process depending on device configuration.
Bug: 113174748
Test: Device boots up and able to make wifi connection.
Test: Tested hotspot functionality.
Test: Ran WifiManagerTest & WifiSoftApTest ACTS tests locally.
Test: Will send for wifi regression tests.
Change-Id: Id19643a235bf0c28238f2729926b893ac2025b97
(cherry-picked from c7aa90091e6bec70a31a643cc4519a9a86fb0b38)
These denials are intermittent and unnecessary. Hide them while we
investigate how to properly fix the issue.
Bug: 131096543
Bug: 132093726
Test: Build
Change-Id: I1950c10a93d183c19c510f869419fcfccd5006d2
(cherry picked from commit 654ceeb93f)
The backup system service will move its storage location to per-user CE
directories to support multiple users. Add additional iterations on the
existing rules to support the new location.
/data/backup -> /data/system_ce/[user id]/backup
Previously covered by rule backup_data_file
/cache/backup -> /data/system_ce/[user id]/backup_stage
Previously covered by rule cache_backup_file
Also add support for vold to create and perform restorecon on the new
locations.
Example denials and detailed proposal in the doc on the linked bug.
Bug: 121197420
Test: 1) Boot device; check dirs created with correct label; run backup
successfully on system user
2) Create secondary user; check dirs created with correct label; run
backup successfully
Change-Id: I47faa69cd2a6ac55fb762edbf366a86d3b06ca77
Define a rollback_data_file label and apply it to the snapshots
directory. This change contains just enough detail to allow
vold_prepare_subdirs to prepare these directories correctly.
A follow up change will flesh out the access policy on these
directories in more detail.
Test: make, manual
Bug: 112431924
Change-Id: I4fa7187d9558697016af4918df6e34aac1957176
This is PS1 of aosp/828283 which was reverted. Using PS1 shouldn't cause
the same issue.
Test: vold is able to create directories, ag/5534962
Bug: 116528212
Change-Id: I84aca49a8dae0a087498120780dea0962aca04b3
This reverts commit 92bde4b941.
Reason for revert: Rebooting after OTA fails due to the
filesystem still seeing the old label on the device.
Bug: 116528212
Bug: 119747564
Change-Id: Ib5f920f85c7e305e89c377369dca038d2c6c738c
Test: rollback change
kernel commit 2a4c22426955d4fc04069811997b7390c0fb858e (fs: switch order
of CAP_DAC_OVERRIDE and CAP_DAC_READ_SEARCH checks) swapped the order of
dac_override and dac_read_search checks. Domains that have dac_override
will now generate spurious denials for dac_read_search unless they also
have that permission. Since dac_override is a strict superset of
dac_read_search, grant dac_read_search to all domains that already have
dac_override to get rid of the denials.
Bug: 114280985
Bug: crbug.com/877588
Test: Booted on a device running 4.14.
Change-Id: I5c1c136b775cceeb7f170e139e8d4279e73267a4
shipping API version:
For devices shipped on O-MR1 nothing changes, data is stored
under /data/system/users/<user-id>/fpdata/...
Devices shipped from now on will instead store fingerprint data under
/data/vendor_de/<user-id>/fpdata.
Support for /data/vendor_de and /data/vendor_ce has been added to vold.
Bug: 36997597
Change-Id: Ibc7cc33b756f64abe68a749c0ada0ca4f6d92514
Merged-In: Ibc7cc33b756f64abe68a749c0ada0ca4f6d92514
Test: manually
(cherry picked from commit 6116daa71a)
Bug: 78591623
Test: Create a new user with a fingerprint. Reboot. Delete that user.
Check for denials, files left over in /data/*_{c,d}e/10
Merged-In: Ib818e112a98c5b954ee829e93ebd69c3b12940cf
Change-Id: Ib818e112a98c5b954ee829e93ebd69c3b12940cf
After adding a new user, deleting it, and rebooting, some of the user's data still remained. This adds the SELinux permissions necessary to remove all of the data. It fixes the followign denials:
avc: denied { rmdir } for scontext=u:r:vold_prepare_subdirs:s0 tcontext=u:object_r:system_data_file:s0 tclass=dir
avc: denied { unlink } for scontext=u:r:vold_prepare_subdirs:s0 tcontext=u:object_r:system_data_file:s0 tclass=file
Bug: 74866238
Test: Create user, delete user, reboot user, see no denials or
leftover data.
Change-Id: Ibc43bd2552b388a9708bf781b5ad206f21df62dc
Restrictions introduced in vendor init mean that new devices
may not no longer exempt vendor init from writing to system_data_file.
This means we must introduce a new label for /data/vendor which
vendor_init may write to.
Bug: 73087047
Test: build and boot Taimen and Marlin. Complete SUW, enroll fingerprint
No new denials.
Change-Id: I65f904bb28952d4776aab947515947e14befbe34
In kernel 4.7, the capability and capability2 classes were split apart
from cap_userns and cap2_userns (see kernel commit
8e4ff6f228e4722cac74db716e308d1da33d744f). Since then, Android cannot be
run in a container with SELinux in enforcing mode.
This change applies the existing capability rules to user namespaces as
well as the root namespace so that Android running in a container
behaves the same on pre- and post-4.7 kernels.
This is essentially:
1. New global_capability_class_set and global_capability2_class_set
that match capability+cap_userns and capability2+cap2_userns,
respectively.
2. s/self:capability/self:global_capability_class_set/g
3. s/self:capability2/self:global_capability2_class_set/g
4. Add cap_userns and cap2_userns to the existing capability_class_set
so that it covers all capabilities. This set was used by several
neverallow and dontaudit rules, and I confirmed that the new
classes are still appropriate.
Test: diff new policy against old and confirm that all new rules add
only cap_userns or cap2_userns;
Boot ARC++ on a device with the 4.12 kernel.
Bug: crbug.com/754831
Change-Id: I4007eb3a2ecd01b062c4c78d9afee71c530df95f
AIUI permissions should be in private unless they need to be public.
Bug: 25861755
Test: Boot device, create and remove a user, observe logs
Change-Id: I6c3521d50dab2d508fce4b614d51e163e7c8f3da
