- This allows init to access it.
Bug: 149039306
Test: Flash and confirm that file system can run resize2fs when metadata_csum is enabled.
Change-Id: Id91d8fb6800b254b12eaf93a0e8cb019b55d2702
Setting files and dirs under /data/incremental as apk_data_file, so that
they will have the same permissions as the ones under /data/app.
Current layout of the dirs:
1. /data/incremental/[random]/mount -> holds data files (such as base.apk) and
control files (such as .cmd). Its subdirectory is first bind-mounted to
/data/incremental/tmp/[random], eventually bind-mounted to
/data/app/~~[randomA]/[packageName]-[randomB].
2. /data/incremental/[random]/backing_mount -> hold incfs backing image.
3. /data/incremental/tmp/[random] -> holds temporary mountpoints (bind-mount targets)
during app installation.
Test: manual
Change-Id: Ia5016db2fa2c7bad1e6611d59625731795eb9efc
4eae75c9d4
Reason for revert: This undoes the previous reversion, which was made to fix b/148282665.
Change-Id: I70d6e60a0468abea19f5efd7fde10207a251cf61
/mnt/pass_through was introduced to allow the FUSE daemon unrestricted
access to the lower filesystem (or sdcardfs).
At zygote fork time, the FUSE daemon will have /mnt/pass_through/0
bind mounted to /storage instead of /mnt/user/0. To keep /sdcard
(symlink to /storage/self/primary) paths working, we create a
'self' directory with an additional 'primary' symlink to
/mnt/pass_through/0/emulated/0 which is a FUSE mount point.
The following components need varying sepolicy privileges:
Vold: Creates the self/primary symlink and mounts the lower filesystem
on /mnt/pass_through/0/emulated. So needs create_dir and mount access
+ create_file access for the symlink
zygote: In case zygote starts an app before vold sets up the paths.
This is unlikely but can happen if the FUSE daemon (a zygote forked app)
is started before system_server completes vold mounts.
Same sepolicy requirements as vold
installd: Needs to clear/destroy app data using lower filesystem
mounted on /mnt/pass_through so needs read_dir access to walk
/mnt/pass_through
priv_app (FUSE daemon): Needs to server content from the lower
filesystem mounted on /mnt/pass_through so needs read_dir access to
walk /mnt/pass_through
Bug: 135341433
Test: adb shell ls /mnt/pass_through/0/self/primary
Change-Id: I16e35b9007c2143282600c56adbc9468a1b7f240
We are updating apps' apk path to have a two-level structure.
Default apk path of an installed app:
Before: /data/app/[packageName]-[randomString]/base.apk
After: /data/app/[randomStringA]/[packageName]-[randomStringB]/base.apk
As a result, the oat files will be two levels below /data/app.
Test: manual
BUG: 148237378
Change-Id: If8e1fed46096f2e5f4150f6eedf74af76ac9d4b4
Revert submission 1209453-aidl-lazy-presubmit
Reason for revert: b/148282665. A test has begun to fail on git_stage-aosp-master, and I need to verify whether these changes are responsible.
Reverted Changes:
Ib09a2460e: Add aidl_lazy_test to general-tests
Ib08989356: Move aidl_lazy_test_server to system_ext
I694e6ad35: Add aidl_lazy_test_server to Cuttlefish
I65db12c63: Add aidl_lazy_test to presubmit
I7ec80a280: Dynamically stop services with multiple interfaces...
Change-Id: I55f6b0f7800f348259787f62c6faa19a90f8bdcc
The steps involved in setting up profiling and stack unwinding are
described in detail at go/perfetto-perf-android.
To summarize the interesting case: the daemon uses cpu-wide
perf_event_open, with userspace stack and register sampling on. For each
sample, it identifies whether the process is profileable, and obtains
the FDs for /proc/[pid]/{maps,mem} using a dedicated RT signal (with the
bionic signal handler handing over the FDs over a dedicated socket). It
then uses libunwindstack to unwind & symbolize the stacks, sending the
results to the central tracing daemon (traced).
This patch covers the app profiling use-cases. Splitting out the
"profile most things on debug builds" into a separate patch for easier
review.
Most of the exceptions in domain.te & coredomain.te come from the
"vendor_file_type" allow-rule. We want a subset of that (effectively all
libraries/executables), but I believe that in practice it's hard to use
just the specific subtypes, and we're better off allowing access to all
vendor_file_type files.
Bug: 137092007
Change-Id: I4aa482cfb3f9fb2fabf02e1dff92e2b5ce121a47
System_server will listen on incoming packets from zygotes.
Bug: 136036078
Test: atest CtsAppExitTestCases:ActivityManagerAppExitInfoTest
Change-Id: I42feaa317615b90c5277cd82191e677548888a71
This patch adds the necessary rules to support the existing usage of
perf_event_open by the system partition, which almost exclusively
concerns the simpleperf profiler. A new domain is introduced for some
(but not all) executions of the system image simpleperf. The following
configurations are supported:
* shell -> shell process (no domain transition)
* shell -> debuggable app (through shell -> runas -> runas_app)
* shell -> profileable app (through shell -> simpleperf_app_runner ->
untrusted_app -> simpleperf)
* debuggable/profile app -> self (through untrusted_app -> simpleperf)
simpleperf_app_runner still enters the untrusted_app domain immediately
before exec to properly inherit the categories related to MLS. My
understanding is that a direct transition would require modifying
external/selinux and seapp_contexts as with "fromRunAs", which seems
unnecessarily complex for this case.
runas_app can still run side-loaded binaries and use perf_event_open,
but it checks that the target app is exactly "debuggable"
(profileability is insufficient).
system-wide profiling is effectively constrained to "su" on debug
builds.
See go/perf-event-open-security for a more detailed explanation of the
scenarios covered here.
Tested: "atest CtsSimpleperfTestCases" on crosshatch-user/userdebug
Tested: manual simpleperf invocations on crosshatch-userdebug
Bug: 137092007
Change-Id: I2100929bae6d81f336f72eff4235fd5a78b94066
This is a test service for testing dynamic start/stop of AIDL services. In order to test realistic use cases with SELinux enabled, it requires the same permissions as a regular service.
Bug: 147153962
Test: aidl_lazy_test aidl_lazy_test_1 aidl_lazy_test_2
Change-Id: Ifc3b2eaefba9c06c94f9cf24b4474107d4e26563
Adding two labels: "incfs" for the incremental filesystem and
"incremental_root_file" for file paths /data/incremental/*.
Doc: go/incremental-selinux
Test: manual
Change-Id: I7d45ed1677e3422119b2861dfc7b541945fcb7a2
Zygote/Installd now can do the following operations in app data directory:
- Mount on it
- Create directories in it
- Mount directory for each app data, and get/set attributes
Bug: 143937733
Test: No denials at boot
Test: No denials seen when creating mounts
Change-Id: I6e852a5f5182f1abcb3136a3b23ccea69c3328db
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
Currently linker config locates under /dev, but this makes some problem
in case of using two system partitions using chroot. To match system
image and configuration, linker config better stays under /linkerconfig
Bug: 144966380
Test: m -j passed && tested from cuttlefish
Change-Id: Iea67663442888c410f29f8dd0c44fe49e3fcef94
SLCAN setup requires certain ioctls and read/write operations to
certain tty's. This change allows the HAL to set up SLCAN devices while
complying with SEPolicy.
In addition to adding support for SLCAN, I've also included permissions
for using setsockopt. In order for the CAN HAL receive error frames from
the CAN bus controller, we need to first set the error mask and filter
via setsockopt.
Test: manual
Bug: 144458917
Bug: 144513919
Change-Id: I63a48ad6677a22f05d50d665a81868011c027898
/system/bin/iorapd fork+execs into /system/bin/iorap_prefetcherd during
startup
See also go/android-iorap-security for the design doc
Bug: 137403231
Change-Id: Ie8949c7927a98e0ab757bc46230c589b5a496360
This change is part of a topic that moves the recovery resources from the
system partition to the vendor partition, if it exists, or the vendor directory
on the system partition otherwise. The recovery resources are moving from the
system image to the vendor partition so that a single system image may be used
with either an A/B or a non-A/B vendor image. The topic removes a delta in the
system image that prevented such reuse in the past.
The recovery resources that are moving are involved with updating the recovery
partition after an update. In a non-A/B configuration, the system boots from
the recovery partition, updates the other partitions (system, vendor, etc.)
Then, the next time the system boots normally, a script updates the recovery
partition (if necessary). This script, the executables it invokes, and the data
files that it uses were previously on the system partition. The resources that
are moving include the following.
* install-recovery.sh
* applypatch
* recovery-resource.dat (if present)
* recovery-from-boot.p (if present)
This change includes the sepolicy changes to move the recovery resources from
system to vendor. The big change is renaming install_recovery*.te to
vendor_install_recovery*.te to emphasize the move to vendor. Other changes
follow from that. The net result is that the application of the recovery patch
has the same permissions that it had when it lived in system.
Bug: 68319577
Test: Ensure that recovery partition is updated correctly.
Change-Id: If29cb22b2a7a5ce1b25d45ef8635e6cb81103327
Probably flew under the radar because Google only tests on devices that
include devices with a physical /vendor partition.
Test: "make selinux_policy", confirm correct labels on a legacy device
Change-Id: I1aa856c6e3774912d1f4c0a09bbc2d174016f59d
Signed-off-by: Felix <google@ix5.org>
snapshotctl is a shell interface for libsnapshot. After rebooting
into an updated build, on sys.boot_completed, init calls
snapshotctl to merge snapshots. In order to do that, it needs to:
- Talk to gsid to mount and unmount COW images
- read the current slot suffix to do checks (and avoid merging
snapshots when it shouldn't).
- read / write OTA metadata files to understand states of
the snapshot
- delete OTA metadata files once a snapshot is merged
- collapse the snapshot device-mapper targets into a plain
dm-linear target by re-mapping devices on device-mapper
Test: reboot after OTA, see merge completed without denials
Bug: 135752105
Change-Id: Idfe99d4004e24805d56cd0ab2479557f237c2448
- /data/gsi/ota/* now has the type ota_image_data_file. At runtime
during an OTA, update_engine uses libsnapshot to talk to gsid
to create these images as a backing storage of snapshots. These
"COW images" stores the changes update_engine has applied to
the partitions.
If the update is successful, these changes will be merged to the
partitions, and these images will be teared down. If the update
fails, these images will be deleted after rolling back to the
previous slot.
- /metadata/gsi/ota/* now has the type ota_metadata_file. At runtime
during an OTA, update_engine and gsid stores update states and
information of the created snapshots there. At next boot, init
reads these files to re-create the snapshots.
Beside these assignments, this CL also allows gsid and update_engine
to have the these permissions to do these operations.
Bug: 135752105
Test: apply OTA, no failure
Change-Id: Ibd53cacb6b4ee569c33cffbc18b1b801b62265de
Vendors can publish services with servicemanager only on non-Treble
builds. vendor_service_contexts is not meant to be read by
servicemanager.
5bccbfefe4/public/servicemanager.te (22)
Bug: 141333155
Test: create /vendor/etc/selinux/vendor_service_contexts and make sure it is
correctly labeled.
Change-Id: Ib68c50e0cdb2c39f0857a10289bfa26fa11b1b3c
Introduces new domain vendor_boringssl_self_test and runs
/vendor/bin/boringssl_self_test(32|64) in it. New domain
required because boringssl_self_test needs to be in
coredomain in order to reboot the device, but vendor code
may not run in coredomain.
Bug: 141150335
Test: flashall && manually verify no selinux errors logged and that
four flag files are created in /dev/boringssl, two by the
system self tests and two by the vendor.
Change-Id: I46e2a5ea338eddacdfd089f696295dbd16795c5a
* changes:
Separate system_ext_mac_permissions.xml out of system sepolicy.
Separate system_ext_service_contexts out of system sepolicy.
Separate system_ext_property_contexts out of system sepolicy.
Separate system_ext_hwservice_contexts out of system sepolicy.
Separate system_ext_seapp_contexts out of system sepolicy.
Separate system_ext_file_contexts out of system sepolicy.
Separate system_ext_sepolicy.cil out of system sepolicy
Bug: 137712473
Test: boot crosshatch
Test: Moving product sepolicy to system_ext and checks the file contents in
/system_ext/etc/selinux are identical to previous contents in
/product/etc/selinux.
Change-Id: I434e7f23a1ae7d01d084335783255330329c44e9
