- Adapt installd rules for app compilation.
- Add profman rules for checking the profile before compilation. This is new behavior compared to installd.
Bug: 229268202
Test: -
1. adb shell pm art optimize-package -m speed-profile -f \
com.google.android.youtube
2. See no SELinux denial.
Change-Id: Idfe1ccdb1b27fd275fdf912bc8d005551f89d4fc
Goal is to gain a better handle on who has access to which maps
and to allow (with bpfloader changes to create in one directory
and move into the target directory) per-map selection of
selinux context, while still having reasonable defaults for stuff
pinned directly into the target location.
BPFFS (ie. /sys/fs/bpf) labelling is as follows:
subdirectory selinux context mainline usecase / usable by
/ fs_bpf no (*) core operating system (ie. platform)
/net_private fs_bpf_net_private yes, T+ network_stack
/net_shared fs_bpf_net_shared yes, T+ network_stack & system_server
/netd_readonly fs_bpf_netd_readonly yes, T+ network_stack & system_server & r/o to netd
/netd_shared fs_bpf_netd_shared yes, T+ network_stack & system_server & netd [**]
/tethering fs_bpf_tethering yes, S+ network_stack
/vendor fs_bpf_vendor no, T+ vendor
* initial support for bpf was added back in P,
but things worked differently back then with no bpfloader,
and instead netd doing stuff by hand,
bpfloader with pinning into /sys/fs/bpf was (I believe) added in Q
(and was definitely there in R)
** additionally bpf programs are accesible to netutils_wrapper
for use by iptables xt_bpf extensions
'mainline yes' currently means shipped by the com.android.tethering apex,
but this is really another case of bad naming, as it's really
the 'networking/connectivity/tethering' apex / mainline module.
Long term the plan is to merge a few other networking mainline modules
into it (and maybe give it a saner name...).
The reason for splitting net_private vs tethering is that:
S+ must support 4.9+ kernels and S era bpfloader v0.2+
T+ must support 4.14+ kernels and T beta3 era bpfloader v0.13+
The kernel affects the intelligence of the in-kernel bpf verifier
and the available bpf helper functions. Older kernels have
a tendency to reject programs that newer kernels allow.
/ && /vendor are not shipped via mainline, so only need to work
with the bpfloader that's part of the core os.
Bug: 218408035
Test: TreeHugger, manually on cuttlefish
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Change-Id: I674866ebe32aca4fc851818c1ffcbec12ac4f7d4
(cherry picked from commit 15715aea32)
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
Change-Id: Id8771b322d4eb5532eaf719f203ca94035e2a8ed
Merged-In: Id8771b322d4eb5532eaf719f203ca94035e2a8ed
odsign will be writing(metrics) to file
/data/misc/odsign/metrics/odsign-metrics.txt & system_server needs from it.
Test: adb pull /data/misc/odsign/metrics/odsign-metrics.txt after reboot
Bug: 202926606
Change-Id: I020efcee8ca7f5b81f1aa3374bbf2b3a7403186d
Add the compos_key_helper domain for the process which has access to
the signing key, make sure it can't be crashdumped. Also extend that
protection to diced & its HAL.
Rename compos_verify_key to compos_verify, because it doesn't verify
keys any more.
Move exec types used by Microdroid to file.te in the host rather than
their own dedicated files.
Bug: 218494522
Test: atest CompOsSigningHostTest CompOsDenialHostTest
Change-Id: I942667355d8ce29b3a9eb093e0b9c4f6ee0df6c1
dmesgd is a daemon that collects kernel memory error reports.
When system_server notices that a kernel error occured, it sets the
dmesgd.start system property to 1, which results in init starting
dmesgd.
Once that happens, dmesgd runs `dmesg` and parses its output to collect
the last error report. That report, together with the headers containing
device- and build-specific information is stored in Dropbox.
Empirically, dmesgd needs the following permissions:
- execute shell (for popen()) and toolbox (for dmesg),
read system_log (for dmesg)
- read /proc/version (to generate headers)
- perform Binder calls to servicemanager and system_server,
find dropbox_service (for dropbox)
- create files in /data/misc/dmesgd (to store persistent state)
Bug: 215095687
Test: run dmesgd on a user device with injected KFENCE bugs
Change-Id: Iff21a2ffd99fc31b89a58ac774299b5e922721ea
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
composd spawns odrefresh in its usual domain. odrefresh then spawns
fd_server in a different domain, and makes binder calls back to
composd to perform individual compilation steps.
fd_server is fairly generic, and part of the virt APEX, but this
instance is specific to composd (e.g. it has access to ART files), so
I named the domain composd_fd_server.
Bug: 186126194
Test: Run composd_cmd, artifacts generated
Change-Id: I5a431dd00b5b396a67021c618fc6edcfb25aa21b
This reverts commit 7ed2456b45.
Reason for revert: /dev/userspace-panic is discarded (b/188777408#comment13)
Bug: 188777408
Change-Id: I98b0159890ee755ffaefc5533f9c40d54f8f26d2
Define type userspace_panic_device and macro userpanic_use for init,
llkd, and system_server to access /dev/userspace_panic - a kernel file
node for userspace processes to request kernel panic.
Bug: 188777408
Change-Id: I1e9d115d85f664aa84bdd6bb4b95bdb48e3aab9a
Grant access to odsign to read & delete pending key files. Eventually
we will grant the CompOS daemon write access.
Bug: 190166662
Test: Via odsign; no denials seen.
Change-Id: I6d3c3e5b2aec8ef65bd28cbb274d18263534ce66
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
Bug: 184131523
Test: atest VirtualizationTestCases
Test: flashed on VIM3L and ran microdroid manually
Change-Id: I6d1b69b63debf44431cd542a0ee85748fcc4191b
Metrics are written to /data/misc/odrefresh by odrefresh during early
boot, then native code in ART system_server initialization passes them
to statsd and deletes the metrics files. This hand-off is necessary
because statsd does not start until after odsign and odrefresh have run.
Bug: 169925964
Test: manual
Change-Id: I8054519a714907819886dd6e5e78f3b5796d0898
Revert submission 1602413-derive_classpath
Bug: 180105615
Fix: 183079517
Reason for revert: SELinux failure leading to *CLASSPATH variables not being set in all builds
Reverted Changes:
I6e3c64e7a:Introduce derive_classpath service.
I60c539a8f:Exec_start derive_classpath on post-fs-data.
I4150de69f:Introduce derive_classpath.
Change-Id: I17e2cd062d8fddc40250d00f02e40237ad62bd6a
The service generates /data/system/environ/classpath with values for
BOOTCLASSPATH, SYSTEMSERVERCLASSPATH, and DEX2OATCLASSPATH to be
exported by init.
See go/updatable-classpath for more details.
Bug: 180105615
Test: manual
Change-Id: I4150de69f7d39f685a202eb4f86c27b661f808dc
The persistent data block is protected by a copy-on-write scratchpad when
running a Dynamic System Update (DSU). The copy-on-write scratchpad
uses a backing file for write operations. This CL adds permissions
to write the backing file for the PersistentDataBlockService.
Bug: 175852148
Test: gsi_tool install & vts_kernel_net_tests
Change-Id: Id0efe407e707fc382679c0eee249af52f877f5d2
The updated font files will be stored to /data/fonts/files and
all application will read it for drawing text.
Thus, /data/fonts/files needs to be readable by apps and only writable
by system_server (and init).
Bug: 173517579
Test: atest CtsGraphicsTestCases
Test: Manually done
Change-Id: Ia76b109704f6214eb3f1798e8d21260343eda231
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
Feature description: if a background trace is happening at the
time dumpstate is invoked, the tracing daemon will snapshot
the trace into a fixed path (/data/misc/perfetto-traces/bugreport/).
Dumpstate will attach the trace, if present, to the bugreport.
From a SELinux viewpoint this involves the following permissions:
- Allow dumpstate to exec+trans perfetto --save-for-bugreport
(this will just send an IPC to traced, which will save the trace).
- Allow dumpstate to list, read and unlink the trace file.
- Create a dedicated label for bugreport traces, to prevent that
dumpstate gets access to other traces not meant for bug reporting.
Note that this does NOT allow dumpstate to serialze arbitary traces.
Traces must be marked as "eligible for bugreport" upfront in the
trace config (which is not under dumpstate control), by
setting bugreport_score > 0.
Design doc: go/perfetto-betterbug
Bug: 170334305
Test: manual:
1. start a perfetto trace with bugreport_score > 0
2. adb shell dumpstate
3. check that the bugreport zip contains the trace
Change-Id: I259c3ee9d5be08d6b22c796b32875d7de703a230
Users are unable to pass config files directly to
perfetto via `perfetto -c /path/to/config` and have to
resort to awkward quirks like `cat config | perfetto -c -'.
This is because /system/bin/perfetto runs in its own SELinux
domain for reasons explained in the bug.
This causes problem to test infrastructures authors. Instead
of allowing the use of /data/local/tmp which is too ill-scoped
we create a dedicated folder and allow only shell and perfetto
to operate on it.
Bug: 170404111
Test: manual, see aosp/1459023
Change-Id: I6fefe066f93f1f389c6f45bd18214f8e8b07079e
This does not yet list all the required capabilities for profcollectd,
but it at least allows the service to start under permissive mode.
Bug: 79161490
Test: start profcollectd
Change-Id: I92c6192fa9b31840b2aba26f83a6dc9f9e835030
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
