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
- /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
Sepolicy for linkerconfig generator and ld.config.txt file from
generator
Bug: 135004088
Test: m -j & tested from device
Change-Id: I2ea7653a33996dde67a84a2e7a0efa660886434a
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
There are multiple trusted system components which may be responsible
for creating executable code within an application's home directory.
Renderscript is just one of those trusted components.
Generalize rs_data_file to app_exec_data_file. This label is intended to
be used for any executable code created by trusted components placed
into an application's home directory.
Introduce a typealias statement to ensure files with the previous label
continue to be understood by policy.
This change is effectively a no-op, as it just renames a type, but
neither adds or removes any rules.
Bug: 121375718
Bug: 112357170
Test: cts-tradefed run cts-dev -m CtsRenderscriptTestCases
Change-Id: I17dca5e3e8a1237eb236761862174744fb2196c0
When an app uses renderscript to compile a Script instance,
renderscript compiles and links the script using /system/bin/bcc and
/system/bin/ld.mc, then places the resulting shared library into the
application's code_cache directory. The application then dlopen()s the
resulting shared library.
Currently, this executable code is writable to the application. This
violates the W^X property (https://en.wikipedia.org/wiki/W%5EX), which
requires any executable code be immutable.
This change introduces a new label "rs_data_file". Files created by
/system/bin/bcc and /system/bin/ld.mc in the application's home
directory assume this label. This allows us to differentiate in
security policy between app created files, and files created by
renderscript on behalf of the application.
Apps are allowed to delete these files, but cannot create or write these
files. This is enforced through a neverallow compile time assertion.
Several exceptions are added to Treble neverallow assertions to support
this functionality. However, because renderscript was previously invoked
from an application context, this is not a Treble separation regression.
This change is needed to support blocking dlopen() for non-renderscript
/data/data files, which will be submitted in a followup change.
Bug: 112357170
Test: cts-tradefed run cts -m CtsRenderscriptTestCases
Change-Id: Ie38bbd94d26db8a418c2a049c24500a5463698a3
This includes the SELinux policy changes to allow for
kcov access in userdebug builds for coverage-guided
kernel fuzzing.
Bug: 117990869
Test: Ran syzkaller with Android untrusted_app sandbox with coverage.
Change-Id: I1fcaad447c7cdc2a3360383b5dcd76e8a0f93f09
Instead of having statsd linking the perfetto client library
and talk directly to its socket, we let just statsd exec()
the /system/bin/perfetto cmdline client.
There are two reasons for this:
1) Simplify the interaction between statsd and perfetto, reduce
dependencies, binary size bloat and isolate faults.
2) The cmdline client also takes care of handing the trace to
Dropbox. This allows to expose the binder interaction surface
to the short-lived cmdline client and avoid to grant binder
access to the perfetto traced daemon.
This cmdline client will be used by:
- statsd
- the shell user (for our UI and Studio)
Bug: 70942310
Change-Id: I8cdde181481ad0a1a5cae5937ac446cedac54a1f
Add a label to /proc/config.gz, so we can distinguish this file from
other /proc files in security policy.
For now, only init is allowed read access. All others are denied.
TODO: clarify exactly who needs access. Further access will be granted
in a future commit.
Bug: 35126415
Test: policy compiles and no device boot problems.
Change-Id: I8b480890495ce5b8aa3f8c7eb00e14159f177860
In order to support platform changes without simultaneous updates from
non-platform components, the platform and non-platform policies must be
split. In order to provide a guarantee that policy written for
non-platform objects continues to provide the same access, all types
exposed to non-platform policy are versioned by converting them and the
policy using them into attributes.
This change performs that split, the subsequent versioning and also
generates a mapping file to glue the different policy components
together.
Test: Device boots and runs.
Bug: 31369363
Change-Id: Ibfd3eb077bd9b8e2ff3b2e6a0ca87e44d78b1317
