The default policy for the "lockdown" access vector on Android was
introduced in commit bcfca1a6. While the "confidentiality" permission
was granted to all processes, the "integrity" was marked as
neverallowed.
Upstream, the support for that access vector was removed from kernel
5.16 onwards.
It was found that the "integrity" permission either does not apply to
Android or duplicates other access control (e.g., capabilities
sys_admin).
Instead of simply removing the neverallow rule, the access is granted to
all processes. This will prevent the proliferation of references to this
access vector in vendors' policies and ultimately facilitate its
removal.
Test: presubmit
Bug: 285443587
Bug: 269377822
Bug: 319390252
Change-Id: If2ad34fbbf2c0d29ac54ab5d1be430623f86f1f7
This patch:
* allows for heap and perf profiling of all processes on the system
(minus undumpable and otherwise incompatible domains). For apps, the
rest of the platform will still perform checks based on
profileable/debuggable manifest flags. For native processes, the
profilers will check that the process runs as an allowlisted UID.
* allows for all apps (=appdomain) to act as perfetto tracing data
writers (=perfetto_producer) for the ART java heap graph plugin
(perfetto_hprof).
* allows for system_server to act a perfetto_producer for java heap
graphs.
Bug: 247858731
Change-Id: I792ec1812d94b4fa9a8688ed74f2f62f6a7f33a6
Similarly to /proc/vmstat, apps are not allowed to access this file.
Ignore the audit message, as this is the most reported denial in our
droidfood population.
Test: m selinux_policy
Change-Id: I88ed1aa1bfad33b462d971e739ca65791cb0227b
And allow VS and crosvm access to privapp_data_file, to the same
extent as app_data_file.
Update some comments, move a neverallow to the bottom of the file with
the others.
Bug: 255286871
Test: Install demo app to system/priv-app, see it work without explicit grant.
Change-Id: Ic763c3fbfdfe9b7a7ee6f1fe76d2a74281b69f4f
This only makes it difficult to run (test/demo) apps using AVF. They
have to be pre-installed on the device which is infeasible on
user-build devices.
Removing the guard so that untrusted apps can use virtualizationservice
even on user builds. Note that the use is still gated by the
MANAGE_VIRTUAL_MACHINE permission, which can be granted only by
pre-installing or explicitly via `adb shell pm grant`. So there's no
risk of 3p apps downloaded from the net having its own VM.
Bug: 231080171
Test: run MicrodroidDemoApp on a user build
Merged-In: Ie0b1b9801dd7726633f97456a38bc0ea349013db
Change-Id: Ie0b1b9801dd7726633f97456a38bc0ea349013db
The existing host-side tests for virtualizationservice will be migrated
to device tests. In order for the self-instrumented test apks be able to
talk to the service, re-introduce the allow rule only for the
non-production builds.
Note that the access to the service is still guarded with the app
permission whose protection level now has the 'development' bit. So,
ordinary apks that are not testing-purpose (i.e. no
android:testOnly="true") can't use the service.
Bug: 203483081
Test: run MicrodroidDemoApp
Change-Id: Ia441fc5ca0a1f076d2e267a26e0df7c11730ec94
Remove access from untrusted apps and instead grant it to platform_app
(but on user builds as well as debug).
Also restrict any app from creating a vsock_socket; using an already
created one is fine.
Bug: 193373841
Test: Microdroid demo app now gets a denial
Test: Rebuild demo with certifcate: platform, adb install, no denial
Change-Id: I7be011e05244767a42d4c56e26de792db4fe599d
Bug: http://b/170257616
This allows native code in CTS tests to write their coverage profiles.
Like other cases of this pattern, this is only enabled with the
NATIVE_COVERAGE build parameter, and shouldn't affect release build
configurations.
Test: atest -a CtsNdkBinderTestCases and verify non-zero coverage in
cts/tests/tests/binder_ndk/libbinder_ndk_test/
Change-Id: Id78aa67750f33c4a8ec6e7fcf8418ff23fc27ac7
Remove some allow rules for odsign, since it no longer directly
modifies CompOs files. Instead allow it to run compos_verify_key in
its own domain.
Grant compos_verify_key what it needs to access the CompOs files and
start up the VM.
Currently we directly connect to the CompOs VM; that will change once
some in-flight CLs have landed.
As part of this I moved the virtualizationservice_use macro to
te_macros so I can use it here. I also expanded it to include
additional grants needed by any VM client that were previously done
for individual domains (and then deleted those rules as now
redundant).
I also removed the grant of VM access to all apps; instead we allow it
for untrusted apps, on userdebug or eng builds only. (Temporarily at
least.)
Bug: 193603140
Test: Manual - odsign successfully runs the VM at boot when needed.
Change-Id: I62f9ad8c7ea2fb9ef2d468331e26822d08e3c828
So simpleperf can profile these apps when they are marked to be
profileable/debuggable.
Bug: 192404394
Test: build and run simpleperf to profile com.android.systemui.
Change-Id: Ia2defe725a8fafbcb6c2d20e771b343d8822ccbc
untrusted apps were already granted this policy and we now extend it
to all apps. This allows FileManager apps with the
MANAGE_EXTERNAL_STORAGE permisssion to access USB OTG volumes mounted
on /mnt/media_rw/<vol>.
This permission access in the framework is implemented by granting
those apps the external_storage gid. And at the same time USB volumes
will be mounted on /mnt/media_rw/<vol> with the external_storage gid.
There is no concern of interferring with FUSE on USB volumes because
they are not FUSE mounted.
For sdcards (non-USB) volumes mounted on /mnt/media_rw/<vol>, those
volumes are mounted with the media_rw gid, so even though they are
FUSE mounted on /storage/<vol>, arbitrary apps cannot access the
/mnt/media_rw path since only the FUSE daemon is granted the media_rw
gid.
Test: Manual
Bug: 182732333
Change-Id: I70a3eb1f60f32d051f44253b0db2c7b852d79ba1
The lockdown hook defines 2 modes: integrity and confidentiality [1].
The integrity mode ensures that the kernel integrity cannot be corrupted
by directly modifying memory (i.e. using /dev/mem), accessing PCI
devices, interacting with debugfs, etc. While some of these methods
overlap with the current policy definition, there is value in enforcing
this mode for Android to ensure that no permission has been overly
granted. Some of these detection methods use arbitrary heuristic to
characterize the access [2]. Adapt part of the policy to match this
constraint.
The confidentiality mode further restricts the use of other kernel
facilities such as tracefs. Android already defines a fine-grained
policy for these. Furthermore, access to part of tracefs is required in
all domains (see debugfs_trace_marker). Allow any access related to this
mode.
[1] https://lore.kernel.org/linux-api/20190820001805.241928-4-matthewgarrett@google.com/
[2] https://lore.kernel.org/linux-api/20190820001805.241928-27-matthewgarrett@google.com/
Bug: 148822198
Test: boot cuttlefish with patched kernel; check logcat for denials.
Test: run simpleperf monitor to exercise tracefs; check logcat for denials.
Change-Id: Ib826a0c153771a61aae963678394b75faa6ca1fe
debugfs_tracing can only be accessed by tracing tools provided by the
platform.
Bug: 172028429
Test: boot with no relevant log showing up
Change-Id: I412dd51a1b268061c5a972488b8bc4a0ee456601
Certain classes of 3rd party apps aren't untrusted_app_domain, but
some comments surrounding this are either outdated or wrong.
Bug: 168753404
Test: N/A
Change-Id: I019c16e26a3778536132f22c37fbea5ae7781af4
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 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
Apps can cause selinux denials by accessing CE storage
and/or external storage. In either case, the selinux denial is
not the cause of the failure, but just a symptom that
storage isn't ready. Many apps handle the failure appropriately.
These denials are not helpful, are not the cause of a problem,
spam the logs, and cause presubmit flakes. Suppress them.
Bug: 145267097
Test: build
Change-Id: If87b9683e5694fced96a81747b1baf85ef6b2124
Only allow apps targetting < Q and ephemeral apps to open /dev/ashmem.
Ephemeral apps are not distinguishable based on target API. So allow
ephemeral_app to open /dev/ashmem for compatibility reasons.
For sake of simplicity, allow all domains /dev/ashmem permissions other
than "open". Reason being that once we can remove "open" access
everywhere, we can remove the device altogether along with other
permission.
Bug: 134434505
Test: boot crosshatch; browse internet, take picture;
no ashmem_device denials
Change-Id: Ie2464c23d799550722580a21b4f6f344983b43ba
This is needed to get Java heap graphs.
Test: flash aosp; profile system_server with setenforce 1
Bug: 136210868
Change-Id: I87dffdf28d09e6ce5f706782422510c615521ab3
Only allow apps targetting < Q and ephemeral apps to open /dev/ashmem.
Ephemeral apps are not distinguishable based on target API. So allow
ephemeral_app to open /dev/ashmem for compatibility reasons.
For sake of simplicity, allow all domains /dev/ashmem permissions other
than "open". Reason being that once we can remove "open" access
everywhere, we can remove the device altogether along with other
permission.
Bug: 134434505
Test: boot crosshatch; browse internet, take picture;
no ashmem_device denials
Change-Id: Ib4dddc47fcafb2697795538cdf055f305fa77799
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
Chrome Crashpad uses the the dynamic linker to load native executables
from an APK (b/112050209, crbug.com/928422)
Addresses the following denial:
avc: denied { execute_no_trans } for comm="Chrome_IOThread" path="/bionic/bin/linker" dev="loop5" ino=24 scontext=u:r:untrusted_app_27:s0:c106,c256,c512,c768 tcontext=u:object_r:system_linker_exec:s0 tclass=file permissive=0 app=com.android.chrome
Test: compiles and builds.
Change-Id: I14f80592a74c36754c28313e94399258b2c42170
all_untrusted_apps apart from untrusted_app_{25, 27} and mediaprovider
are now expected to go to ashmemd for /dev/ashmem fds.
Give coredomain access to ashmemd, because ashmemd is the default way
for coredomain to get a /dev/ashmem fd.
Bug: 113362644
Test: device boots, ashmemd running
Test: Chrome app works
Test: "lsof /system/lib64/libashmemd_client.so" shows
libashmemd_client.so being loaded into apps.
Change-Id: I279448c3104c5d08a1fefe31730488924ce1b37a
system/sepolicy commit ffa2b61330
introduced the runas_app SELinux domain, which changed how we perform
debugging of Android applications. This broke Android Studio's lldb.
From bugreport:
Debugging an app containing native code using ndk-gdb or Android
Studio's lldb currently fails. There is an selinux error in logcat
about a sigchld denial. Studio can still debug Java-only apps.
In Android Studio, starting the debugger on an app with native
code produces this selinux denial:
01-30 06:58:02.089 13449 13449 W lldb-server: type=1400 audit(0.0:831): avc: denied { sigchld } for scontext=u:r:untrusted_app_27:s0:c167,c256,c512,c768 tcontext=u:r:runas_app:s0:c167,c256,c512,c768 tclass=process permissive=0 app=com.android.ndktestapp
With "set enforce 0", I also see a sigstop denial:
01-30 07:31:12.209 15672 15672 I lldb-server: type=1400 audit(0.0:1290): avc: denied { sigstop } for scontext=u:r:runas_app:s0:c167,c256,c512,c768 tcontext=u:r:untrusted_app_27:s0:c167,c256,c512,c768 tclass=process permissive=1 app=com.android.ndktestapp
In gdb-server.log, Studio reports this error while trying to start lldb-server:
1548831482.091491938 GDBRemoteCommunicationServerLLGS::Handle_vAttach attempting to attach to pid 13379
1548831482.091519117 GDBRemoteCommunicationServerLLGS::AttachToProcess pid 13379
1548831482.092242956 GDBRemoteCommunicationServerLLGS::Handle_vAttach failed to attach to pid 13379: Permission denied
Using ndk-gdb (e.g. on the NdkGdbSample) produces the same sort
of selinux denial:
01-30 07:11:26.742 13926 13926 W arm64-gdbserver: type=1400 audit(0.0:833): avc: denied { sigchld } for scontext=u:r:untrusted_app_27:s0:c166,c256,c512,c768 tcontext=u:r:runas_app:s0:c166,c256,c512,c768 tclass=process permissive=0 app=com.android.developer.ndkgdbsample
If I use "setenforce 0", I see more denials logged (signal and
sigstop):
01-30 07:30:23.346 15478 15478 I arm64-gdbserver: type=1400 audit(0.0:1287): avc: denied { signal } for scontext=u:r:runas_app:s0:c166,c256,c512,c768 tcontext=u:r:untrusted_app_27:s0:c166,c256,c512,c768 tclass=process permissive=1 app=com.android.developer.ndkgdbsample
01-30 07:30:23.349 15478 15478 I arm64-gdbserver: type=1400 audit(0.0:1288): avc: denied { sigstop } for scontext=u:r:runas_app:s0:c166,c256,c512,c768 tcontext=u:r:untrusted_app_27:s0:c166,c256,c512,c768 tclass=process permissive=1 app=com.android.developer.ndkgdbsample
ndk-gdb times out and prints an error:
rprichard@cashew:/x/ndk/ndk/samples/NdkGdbSample$ /x/android-ndk-r19/ndk-gdb --launch
Redirecting gdbserver output to /tmp/gdbclient.log
...
Error: unable to connect to device.
Remote communication error. Target disconnected.: Connection reset by peer.
gdbclient.log shows that gdbserver hasn't started listening to its Unix socket yet:
rprichard@cashew:/x/ndk/ndk/samples/NdkGdbSample$ cat /tmp/gdbclient.log
Attached; pid = 14232
Normal output looks like this:
rprichard@cashew:/x/ndk/ndk/samples/NdkGdbSample$ cat /tmp/gdbclient.log
Attached; pid = 27799
Listening on Unix domain socket '/data/data/com.android.developer.ndkgdbsample/debug_socket'
Remote debugging from host 127.0.0.0
Test: compiles and builds
Bug: 123612207
Change-Id: Ia9a711cc54cc044c0817a7c17eb4506015adb393
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
system/sepolicy commit ffa2b61330 made
run-as spawned processes run in the runas_app SELinux domain, instead of
the untrusted_app domain.
https://android-review.googlesource.com/q/topic:%22runas_exec%22+(status:open%20OR%20status:merged)
This broke unix socket connections from untrusted_app* to runas_app.
This functionality is used by Android Studio for the Instant Run
feature. See https://developer.android.com/studio/run/
Allow untrusted_apps to connect to listening abstract sockets hosted by
runas_app.
Addresses the following denial:
01-23 11:11:56.084 16272 16272 W e.myapplication: type=1400 audit(0.0:68): avc: denied { connectto } for path=006972736F636B6574000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 scontext=u:r:untrusted_app_27:s0:c169,c256,c512,c768 tcontext=u:r:runas_app:s0:c169,c256,c512,c768 tclass=unix_stream_socket permissive=0 app=com.example.myapplication
01-23 11:11:56.086 16272 16272 V SwapperAgent: Prior agent invocations in this VM: 1
01-23 11:11:56.088 16272 16272 E SwapperAgent: Could not connect to socket
Change-Id: Ia1203f44aebcbec0ff858b8316e147cba7a048a2
Fixes: 123297648
Test: acleung manual testing
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
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
This reverts commit 0dd738d810.
Reason for revert: CtsSimpleperfTestCases CTS test case failures.
See b/118704604 for details.
Bug: 112357170
Bug: 118704604
Change-Id: Ibe921f3bbc3404694542ef695883c1a30777d68b
untrusted_app: Remove the ability to run execve() on files within an
application's home directory. Executing code from a writable /home
directory is a W^X violation (https://en.wikipedia.org/wiki/W%5EX).
Additionally, loading code from application home directories violates a
security requirement that all executable code mapped into memory must
come from signed sources, or be derived from signed sources.
Note: this change does *not* remove the ability to load executable code
through other mechanisms, such as mmap(PROT_EXEC) of a file descriptor
from the app's home directory. In particular, functionality like
dlopen() on files in an app's home directory continues to work even
after this change.
untrusted_app_25 and untrusted_app_27: For backwards compatibility,
continue to allow these domains to execve() files from the
application's home directory.
seapp_contexts: Bump the minimum API level required to enter the
untrusted_app domain. This will run API level 27-28 processes in
the API level 27 sandbox. API level 28 will continue to run with
levelFrom=all, and API level 27 will continue to run with
levelFrom=user.
Bug: 112357170
Test: Device boots and no obvious problems.
Test: See CTS test at https://android-review.googlesource.com/c/platform/cts/+/804228
Change-Id: Ief9ae3a227d16ab5792f43bacbb577c1e70185a0
The current rule is missing mmap. r_file_perm implicitly adds mmap, so
we should just use that instead.
Test: policy compiles.
Change-Id: I4051d1eb4c36a2b6ff2b5f26ce53355287cbe2b4
