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
This is needed to get Java heap graphs.
Test: flash aosp; profile system_server with setenforce 1
Bug: 136210868
Change-Id: I87dffdf28d09e6ce5f706782422510c615521ab3
Since this service no longer exists.
Fix: 80317992
Test: TH, codesearch.
Merged-In: I257c8cc3dba657d98f19eb61b36aae147afea393
Change-Id: I257c8cc3dba657d98f19eb61b36aae147afea393
We are only interested in removing "open" access from apps, so leave
apps with (rw_file_perms - open) permissions to /dev/ashmem
Bug: 126627315
Test: emulator boots without denials to /dev/ashmem
Change-Id: I7f03fad5e4e82aebd1b6272e4956b16f86043637
Apps are no longer allowed open access to /dev/ashmem, unless they
target API level < Q.
Bug: 113362644
Test: device boots, Chrome, instant apps work
Change-Id: I1cff08f26159fbf48a42afa7cfa08eafa1936f42
Allow all the app process with GUI to send GPU health metrics stats to
GpuService during the GraphicsEnvironment setup stage for the process.
Bug: 123529932
Test: Build, flash and boot. No selinux denials.
Change-Id: Ic7687dac3c8a3ea43fa744a6ae8a45716951c4df
Untrustworthy symlinks dereferenced by priv-apps could cause those apps
to access files they weren't intending to access. Trusted components
such as priv-apps should never trust untrustworthy symlinks from
untrusted apps.
Modify the rules and add a neverallow assertion to prevent regressions.
Bug: 123350324
Test: device boots and no obvious problems.
Change-Id: I8c4a5c9c8571fd29b2844b20b4fd1126db4128c0
This patch extends the current debug-specific rules to cover user
builds. As a reminder, on user, the target process fork-execs a private
heapprofd process, which then performs stack unwinding & talking to the
central tracing daemon while staying in the target's domain. The central
heapprofd daemon is only responsible for identifying targets & sending
the activation signal. On the other hand, on debug, the central
heapprofd can handle all processes directly, so the necessary SELinux
capabilities depend on the build type.
These rules are necessary but not sufficient for profiling. For zygote
children, the libc triggering logic will also check for the app to
either be debuggable, or go/profileable.
For more context, see go/heapprofd-security & go/heapprofd-design.
Note that I've had to split this into two separate macros, as
exec_no_trans - which is necessary on user, but nice-to-have on debug -
conflicts with a lot of neverallows (e.g. HALs and system_server) for
the wider whitelisting that we do on debug builds.
Test: built & flashed on {blueline-userdebug, blueline-user}, activated profiling of whitelisted/not domains & checked for lack of denials in logcat.
Bug: 120409382
Change-Id: Id0defc3105b99f777bcee2046d9894a2b39c6a29
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
Remove the ability for applications to dlopen() executable code from
their home directory for newer API versions. API versions <= 28 are
uneffected by this change.
Bug: 112357170
Test: cts-tradefed run cts -m CtsRenderscriptTestCases
Change-Id: I1d7f3a1015d54b8610d1c561f38a1a3c2bcf79e4
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
There is a problem with on-disk labeling of files created by secondary
dex background compilation which is causing unexpected denials to show
up. Drop the auditallow rule to avoid logspam.
Steps to reproduce:
1) boot android device.
2) adb root
3) Run cmd package compile -r bg-dexopt --secondary-dex com.google.android.gms
4) Examine the files in /data/user_de/0/com.google.android.gms
Expected:
All files have the label privapp_data_file
Actual:
The files in /data/user_de/0/com.google.android.gms/app_chimera/m
are labeled "app_data_file", not "privapp_data_file".
Addresses the following audit logspam:
type=1400 audit(0.0:117): avc: granted { execute } for comm=4173796E635461736B202331 path="/data/user_de/0/com.google.android.gms/app_chimera/m/00000002/oat/arm/DynamiteLoader.odex" dev="dm-0" ino=5775 scontext=u:r:untrusted_app:s0:c111,c256,c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file app=com.android.chrome
Additionally, this removes auditallow statements for older untrusted
apps. Lots of big apps are executing files from their home directory.
Additional restrictions in this area will need to be tied to API
versions.
Addresses the following audit logspam:
type=1400 audit(0.0:619): avc: granted { execute } for comm="na:notification" path="/data/data/com.facebook.katana/lib-xzs/libbreakpad.so" dev="dm-3" ino=28333 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file app=com.facebook.katana
type=1400 audit(0.0:129): avc: granted { execute } for comm="ticlock" path="/data/data/is.shortcut/files/ticlock/ticlock" dev="dm-3" ino=58614 scontext=u:r:untrusted_app_27:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file app=is.shortcut
type=1400 audit(0.0:1239): avc: granted { execute } for comm="Analytics-Norma" path="/data/data/com.facebook.orca/lib-xzs/libchipsetmerged.so" dev="dm-3" ino=50243 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file app=com.facebook.orca
type=1400 audit(0.0:58): avc: granted { execute_no_trans } for comm="sh" path="/data/data/is.shortcut/files/ticlock/ticlock" dev="dm-3" ino=58614 scontext=u:r:untrusted_app_27:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file app=is.shortcut
type=1400 audit(0.0:1948): avc: granted { execute_no_trans } for comm="sh" path="/data/data/com.mxdata.tube.Market/files/osmcore" dev="sda13" ino=2752651 scontext=u:r:untrusted_app_25:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file app=com.mxdata.tube.Market
type=1400 audit(0.0:2875): avc: granted { execute_no_trans } for comm="ThreadPoolManag" path="/data/data/com.amazon.kindle/files/hardwareTest" dev="sda13" ino=1935346 scontext=u:r:untrusted_app_27:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=file app=com.amazon.kindle
This reverts commit 4738b93db2.
Bug: 112357170
Test: policy compiles
Executing files from an application home directory violates
W^X (https://en.wikipedia.org/wiki/W%5EX) constraints (loading executable code
from a writable file) and is an unsafe application behavior. Test to see if we
can get rid of it and establish some baseline metrics.
Test: device boots and no obvious problems.
Change-Id: I756c281fcbf750821307327642cc0d06605951b0
Currently, both untrusted apps and priv-apps use the SELinux file label
"app_data_file" for files in their /data/data directory. This is
problematic, as we really want different rules for such files. For
example, we may want to allow untrusted apps to load executable code
from priv-app directories, but disallow untrusted apps from loading
executable code from their own home directories.
This change adds a new file type "privapp_data_file". For compatibility,
we adjust the policy to support access privapp_data_files almost
everywhere we were previously granting access to app_data_files
(adbd and run-as being exceptions). Additional future tightening is
possible here by removing some of these newly added rules.
This label will start getting used in a followup change to
system/sepolicy/private/seapp_contexts, similar to:
-user=_app isPrivApp=true domain=priv_app type=app_data_file levelFrom=user
+user=_app isPrivApp=true domain=priv_app type=privapp_data_file levelFrom=user
For now, this newly introduced label has no usage, so this change
is essentially a no-op.
Test: Factory reset and boot - no problems on fresh install.
Test: Upgrade to new version and test. No compatibility problems on
filesystem upgrade.
Change-Id: I9618b7d91d1c2bcb5837cdabc949f0cf741a2837
Because applications should be able to set the receive
timeout on UDP encapsulation sockets, we need to allow
setsockopt(). getsockopt() is an obvious allowance as
well.
Bug: 68689438
Test: compilation
Merged-In: I2eaf72bcce5695f1aee7a95ec03111eca577651c
Change-Id: I2eaf72bcce5695f1aee7a95ec03111eca577651c
This gives the privilege to system apps, platform apps,
ephemeral apps, and privileged apps to receive a
UDP socket from the system server. This is being added
for supporting UDP Encapsulation sockets for IPsec, which
must be provided by the system.
This is an analogous change to a previous change that
permitted these sockets for untrusted_apps:
0f75a62e2c
Bug: 70389346
Test: IpSecManagerTest, System app verified with SL4A
Change-Id: Iec07e97012e0eab92a95fae9818f80f183325c31
Perfetto is a performance instrumentation and logging framework,
living in AOSP's /external/pefetto.
Perfetto introduces in the system one binary and two daemons
(the binary can specialize in either depending on the cmdline).
1) traced: unprivileged daemon. This is architecturally similar to logd.
It exposes two UNIX sockets:
- /dev/socket/traced_producer : world-accessible, allows to stream
tracing data. A tmpfs file descriptor is sent via SCM_RIGHTS
from traced to each client process, which needs to be able to
mmap it R/W (but not X)
- /dev/socket/traced_consumer : privilege-accessible (only from:
shell, statsd). It allows to configure tracing and read the trace
buffer.
2) traced_probes: privileged daemon. This needs to:
- access tracingfs (/d/tracing) to turn tracing on and off.
- exec atrace
- connect to traced_producer to stream data to traced.
init.rc file:
https://android-review.googlesource.com/c/platform/external/perfetto/+/575382/14/perfetto.rc
Bug: 70942310
Change-Id: Ia3b5fdacbd5a8e6e23b82f1d6fabfa07e4abc405
This restriction causes issues with dynamite.
Since untrusted_v2_app was about enforcing this constraint put installed
v2 applications back into the normal untrusted_app domain.
Bug: 64806320
Test: Manual test with app using dynamite module
(cherrypicked from commit fe83681794)
Change-Id: I3abf3ade64aaf689039a515de642759dd39ae6f7
Vendor apps may only use servicemanager provided services
marked as app_api_service. surfaceflinger_service should be
available to vendor apps, so add this attribute and clean up
duplicate grants.
Addresses:
avc: denied { find } scontext=u:r:qtelephony:s0
tcontext=u:object_r:surfaceflinger_service:s0 tclass=service_manager
avc: denied { find } scontext=u:r:ssr_detector:s0
tcontext=u:object_r:surfaceflinger_service:s0 tclass=service_manager
avc: denied { find } scontext=u:r:qcneservice:s0
tcontext=u:object_r:surfaceflinger_service:s0 tclass=service_manager
Bug: 69064190
Test: build
Change-Id: I00fcf43b0a8bde232709aac1040a5d7f4792fa0f
On PRODUCT_FULL_TREBLE devices, non-vendor domains (except vendor
apps) are not permitted to use Binder. This commit thus:
* groups non-vendor domains using the new "coredomain" attribute,
* adds neverallow rules restricting Binder use to coredomain and
appdomain only, and
* temporarily exempts the domains which are currently violating this
rule from this restriction. These domains are grouped using the new
"binder_in_vendor_violators" attribute. The attribute is needed
because the types corresponding to violators are not exposed to the
public policy where the neverallow rules are.
Test: mmm system/sepolicy
Test: Device boots, no new denials
Test: In Chrome, navigate to ip6.me, play a YouTube video
Test: YouTube: play a video
Test: Netflix: play a movie
Test: Google Camera: take a photo, take an HDR+ photo, record video with
sound, record slow motion video with sound. Confirm videos play
back fine and with sound.
Bug: 35870313
Change-Id: I0cd1a80b60bcbde358ce0f7a47b90f4435a45c95
This starts with the reduction in the number of services that
ephemeral apps can access. Prior to this commit, ephemeral apps were
permitted to access most of the service_manager services accessible
by conventional apps. This commit reduces this set by removing access
from ephemeral apps to:
* gatekeeper_service,
* sec_key_att_app_id_provider_service,
* wallpaper_service,
* wifiaware_service,
* wifip2p_service,
* wifi_service.
Test: Device boots up fine, Chrome, Play Movies, YouTube, Netflix, work fine.
Bug: 33349998
Change-Id: Ie4ff0a77eaca8c8c91efda198686c93c3a2bc4b3
The rules for the two types were the same and /data/app-ephemeral is
being removed. Remove these types.
Test: Builds
Change-Id: I520c026395551ad1362dd2ced53c601d9e6f9b28
Ephemeral apps cannot open files from external storage, but can be given
access to files via the file picker.
Test: ACTION_OPEN_DOCUMENTS from an ephemeral app returns a readable fd.
Change-Id: Ie21b64a9633eff258be254b9cd86f282db1509e8
Ephemeral apps are still apps with very similar capabilities, it makes
more sense to have them under appdomain and benefit from the shared
state (and all the neverallow rules) than to try and dupplicate them and
keep them in sync.
This is an initial move, there are parts of ephemeral_app that still
need to be locked down further and some parts of appdomain that should
be pushed down into the various app domains.
Test: Builds, ephemeral apps work without denials.
Change-Id: I1526b2c2aa783a91fbf6543ac7f6d0d9906d70af
This leaves only the existence of ephemeral_app domain as public API.
All other rules are implementation details of this domain's policy and
are thus now private. There are a few rules, defined by other domains'
files remaining in the public policy until the rules from these
domains also move to the private policy:
allow ephemeral_app_current appdomain:binder transfer;
allow ephemeral_app_current audioserver_current:binder transfer;
allow ephemeral_app_current drmserver_current:binder transfer;
allow ephemeral_app_current dumpstate_current:binder transfer;
allow ephemeral_app_current mediaserver_current:binder transfer;
allow ephemeral_app_current surfaceflinger_current:binder transfer;
allow ephemeral_app_current system_server_current:binder transfer;
Test: No change to policy according to sesearch, except for
disappearance of all allow rules from platform_app_current
attribute (as expected).
Bug: 31364497
Change-Id: I98687181434a98a141469ef676c461fcd1db2d4e
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
