public/property split is landed to selectively export public types to
vendors. So rules happening within system should be in private. This
introduces private/property.te and moves all allow and neverallow rules
from any coredomains to system defiend properties.
Bug: 150331497
Test: system/sepolicy/tools/build_policies.sh
Change-Id: I0d929024ae9f4ae3830d4bf3d59e999febb22cbe
Merged-In: I0d929024ae9f4ae3830d4bf3d59e999febb22cbe
(cherry picked from commit 42c7d8966c)
As apexd now has dac_override, it should also have dac_read_search to
avoid spurious denials.
Bug: 141148175
Test: Build, run apex installation, check denials.
Change-Id: I179c05b36ae0fe62d943ca59ee7f8158507f1f10
This allows apexd to execute "cp" to perform snapshot and
restore operations.
Other rules for this were added in aosp/1217340, but this one was
missed.
Bug: 141148175
Test: atest StagedRollbackTest#testRollbackApexDataDirectories_DeSys
Change-Id: Ia529ede468578bfadc87e049a2c0ab4f87e1c43d
This adds rules required for apexd to perform snapshot and restore
of the new apex data directories.
See go/apex-data-directories for more information on the feature.
See the chain of CLs up to ag/10169468 for the implementation of
snapshot and restore.
Bug: 141148175
Test: atest StagedRollbackTest#testRollbackApexDataDirectories_DeSys
Test: atest StagedRollbackTest#testRollbackApexDataDirectories_DeUser
Test: atest StagedRollbackTest#testRollbackApexDataDirectories_Ce
Change-Id: I1756bbc1d80cad7cf9c2cebcee9bee6bc261728c
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
apexd stops itself when it finds that it is running on a device with
flattened APEXes (i.e. ro.apex.updatable = false).
Bug: 133907211
Test: launch sdk_phone_x86_64
adb logcat -d | grep apexd | wc -l
returns 3
Change-Id: I7fa161b069aa34adb028194b55f367fe740a0cfc
apexd needs to read /vendor/apex dir and files in it.
Bug: 131190070
Bug: 123378252
Test: 1. Add apex to /vendor/apex
-> see if boot succeeds with new policy
2. Add flattened apex to /vendor/apex
-> see if only root files are labelled as vendor_apex_file
Change-Id: I37795ab6d659ac82639ba5e34d628fe1b5cdb350
The bootstrap bionic (/system/lib/bootstrap/*) are only to the early
processes that are executed before the bionic libraries become available
via the runtime APEX. Allowing them to other processes is not needed and
sometimes causes a problem like b/123183824.
Bug: 123183824
Test: device boots to the UI
Test: atest CtsJniTestCases:android.jni.cts.JniStaticTest#test_linker_namespaces
Change-Id: Id7bba2e8ed1c9faf6aa85dbbdd89add04826b160
We no longer have /system/etc/security/apex/* as the public keys are all
bundled in APEXes. Removing the selinux label and policies for it.
Bug: 936942
Test: device is bootable
Change-Id: I6b6144a8d15910d1ba8584a0778244ed398dc615
This is an area that apexd can use to store session metadata, which
won't be rolled back with filesystem checkpointing.
Bug: 126740531
Test: builds
Change-Id: I5abbc500dc1b92aa46830829be76e7a4381eef91
This is needed in cases SELinux labels are restored under /data/apex by
an external process calling restorecon. In normal condition files under
/data/apex/active retain the label staging_data_file used at their
original creation by StagingManager. However, we observed that the label
might be changed to apex_data_file, which we were able to reproduce by
running restorecon.
Explicitly mark files under /data/apex/active and /data/apex/backup as
staging_data_file.
This CL also remove some stale rules being addressed since.
Test: ran restorecon on files in /data/apex/active, attempted installing
a new apex which triggered the violation when files are linked to
/data/apex/backup. With this CL, the operation succeeds.
Bug: 112669193
Change-Id: Ib4136e9b9f4993a5b7e02aade8f5c5e300a7793c
Add art_apex_postinstall domain that is allowed to move
precreated AoT artifacts from /data/ota.
Bug: 125474642
Test: m
Change-Id: Id674e202737155a4ee31187f096d1dd655001fdd
Add art_apex_preinstall domain that is allowed to create AoT
artifacts in /data/ota.
Bug: 125474642
Test: m
Change-Id: Ia091d8df34c4be4f84c2052d3c333a0e36bcb036
In some scenarios (native watchdog finding a regression, apexd failing
to mount apexes), a rollback of apexd will be triggered which requires
device reboot.
Bug: 123622800
Test: manually triggered apexd rollback and verified it reboots phone
Change-Id: I4c5d785a69dd56a63348c75c1897601749db9bc5
In order to support rollback for apex files, apexd will need to unlink
previously active apex files in /data/apex/active folder. Those files
are hardlinked from /data/staging/session_XXXX which means that they
have staging_data_file:file SELinux fields.
I double checked that this change won't allow apexd to unlink files in
/data/staging/session_XXXX folders, because it will lack write access,
logcat contains following entries:
avc: denied { write } for name="session_305119585" dev="sda13" ino=5496838 scontext=u:r:apexd:s0 tcontext=u:object_r:staging_data_file:s0 tclass=dir permissive=0
Bug: 122339211
Test: verified that apexd can't unlink files in /data/staging/session_XXXX
Change-Id: Iddef724c3d73269c97d9fa12a05a276fad189ea9
Different devices can have /sys/* labeled differently. This allows
apexd, to traverse /sys directory tree agnostic of device-specific
labeling.
Bug: 122876102
Test: m selinux_policy
Change-Id: I08f2eb2242913e3a7d532d36a452cf111fd4e4c4
Give apexd permission to execute sh.
Add userdebug_or_eng domains and rules for the test
APEX for pre- and post-install.
Bug: 119260955
Bug: 119261380
Test: atest apexservice_test
Change-Id: I0c4a5e35e096101a53c9d1f212d2db2e63728267
Allow apexd to log to the kernel log. This aids in low-level
diagnostics, when adb is not available.
Test: m
Change-Id: Ib8f286bd917b34f5e8992b37ab230313a4820bf9
For consistency with APKs, signature verification is performed
in the system_server. This includes checking that the signature of
an updated install matches the signature of the active package that
it updates. For this, it requires search access to /data/apex and
read access to the files under that directory.
Test: m
Change-Id: Ia073adb8892886e4767fa5529e95c110b9cbff1b
Test: basic workflow between apexd and PackageManager tested with
changes being developed.
Bug: 118865310
Change-Id: I1ae866f33e9b22493585e108c4fd45400493c7ac
To configure read-ahead on loop devices, eg.
/sys/devices/virtual/block/loop0/queue/read_ahead_kb
Bug: 120776455
Test: configuring read-ahead on loop devices works from apexd
Change-Id: Ib25372358e8ca62fa634daf286e4b64e635fac58
To work around a kernel bug where pages that are read before changing
the loop device offset are not invalidated correctly.
Bug: 120853401
Test: apexd mounts APEX files on gphone_sdk_x86_64
Change-Id: I89f23f8f9d472e599f053553b73cc0618dcb3747
Currently, when an APEX is staged, apexd moves the file from
/data/app/vmdl*.tmp directory to /data/apex. However, the original file
is labeled with apk_tmp_file and is not readable from apexd.
We plan to resolve this issue by moving the file content via file
descriptor in between the package manager and apexd.
However, until the plan is implemented, temporarily allow apexd to
relabel the file to apex_data_file that is readable to it. This unblocks
the end-to-end test for APEX.
Bug: 112669193
Test: adb install --apex system/apex/apexd/apexd_testdata/test.apex
adb reboot; adb root; adb shell; cmd apexservice getActivePackages
The test APEX is activated
Change-Id: Ib9d4f5c699261f1fa1e6d557731767ee4d7168f9
In earlier kernel versions (<4.0), the loopback driver issues
requests from a kernel thread. Therefore, the kernel needs access
to APEX file descriptors and data files (which are loopback
mounted).
Bug: 119220815
Test: mounting works on sailfish
Change-Id: I75b2bade41c64cf6fa6040d9c2f5489a206e04c6
apexd is using following additional ioctl cmds to mount the mini
filesystem inside APEXs:
LOOP_SET_STATUS64
LOOP_SET_FD
LOOP_SET_BLOCK_SIZE
LOOP_SET_DIRECT_IO
LOOP_CLR_FD
Test: m; m apex.test; adb push <the_built_apex> /data/apex; adb reboot
/apex/com.android.example.apex exists
Change-Id: I68388cc4f323e4fcff370c8cdc0958cbd827e9cc
Start enforcing the use of ioctl restrictions on all Android block
devices. Domains which perform ioctls on block devices must be explicit
about what ioctls they issue. The only ioctls allowed by default are
BLKGETSIZE64, BLKSSZGET, FIOCLEX, and FIONCLEX.
Test: device boots and no problems.
Change-Id: I1195756b20cf2b50bede1eb04a48145a97a35867
apexd uses realpath(3) to ensure that the public key file that will use
is under /system/etc/security/apex directory. In order to support it,
allow apexd to getattr on apex_key_files.
The canonicalization is required because the key name from APEX might be
wrong. For example, if the key name from an APEX is '../../some/path'
then apexd will use '/system/etc/security/apex/../../some/path' as the
public key file, which is incorrect.
Bug: 115721587
Test: m apex.test; m
/apex/com.android.example.apex@1 exists
Change-Id: I6dc5efa0de369f8497e4f6526e0164e2de589c67
apexd is a new daemon for managing APEX packages installed
on the device. It hosts a single binder service, "apexservice".
Bug: 112455435
Test: builds, binder service can be registered,
apexes can be accessed, verified and mounted
Change-Id: I634ad100f10b2edcd9a9c0df0d33896fa5d4ed97
