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
