This gives us an easy way for the policy to refer to all existing or
future types used for app private data files in type= assignments in
seapp_contexts.
Apply the label to all the existing types, then refactor rules to use
the new attribute.
This is intended as a pure refactoring, except that:
- Some neverallow rules are extended to cover types they previous
omitted;
- We allow iorap_inode2filename limited access to shell_data_file and
nfc_data_file;
- We allow zygote limited access to system_app_data_file.
This mostly reverts the revert in commit
b01e1d97bf, restoring commit
27e0c740f1. Changes to check_seapp to
enforce use of app_data_file_type is omitted, to be included in a
following CL.
Test: Presubmits
Bug: 171795911
Change-Id: I02b31e7b3d5634c94763387284b5a154fe5b71b4
This gives us an easy way for the policy to refer to all existing or
future types used for app private data files in type= assignments in
seapp_contexts.
Apply the label to all the existing types, then refactor rules to use
the new attribute.
This is intended as a pure refactoring, except that:
- Some neverallow rules are extended to cover types they previous
omitted;
- We allow iorap_inode2filename limited access to shell_data_file and
nfc_data_file;
- We allow zygote limited access to system_app_data_file.
Also extend check_seapp to check that all types specified in
seapp_contexts files have the attribute, to ensure that the neverallow
rules apply to them. As a small bonus, also verify that domain and
type values are actually types not attributes.
Test: Presubmits
Test: Manual: specify an invalid type, build breaks.
Bug: 171795911
Change-Id: Iab6018af449dab3b407824e635dc62e3d81e07c9
Also make shared_relro_file mlstrustedobject to ensure these files can
still be read by any app in any user.
Bug: 170622707
Test: Manual: delete the files, check they are re-created and accessible.
Test: Manual: no denials seen
Test: Presubmits
Change-Id: Icce4ee858219e3fd0e307f3edfb3c66005872a45
In moving Traceur from being signed with the platform key to privapp
status, we need to adjust how SELinux identifies the Traceur
app_context. We remove the platform seinfo identifier since Traceur is
no longer a platform app, and identify it as a privapp.
Bug: 166768816
Test: Build user and userdebug versions, tested regular and long tracing
functionality
Change-Id: Ie0b198a0caa5c3a074f5a275c7eb95e37671d60f
com.android.permissioncontroller was getting routed to platform_app
since specified seinfo takes precedence over unspecified seinfo. This
change adds seinfo=platform to the rule for
com.android.permissioncontroller so it correctly runs in the
permissioncontroller_app domain.
Bug: 158953123
Test: Treehugger + android.security.cts.SELinuxHostTest#testPermissionControllerDomain
Change-Id: I721fbf43a9774ed11414dd084bedaeb7216a76dd
The mapping of UIDs to categories can only take 16 bits, yet isolated
processes start at UID 90000. Additionally, the main purpose of these
categories was to isolate app-private storage, but since isolated
processes don't have access to app-private storage anyway, removing them
doesn't hurt.
The upside is that this allows us to remove mIstrustedsubject from the
app_zygote domain, which prevents app code running in that context from
assigning itself arbitrary categories.
Bug: 157598026
Test: inspect categories of app_zygote and children; verify Chrome works
Merged-In: Idfa8625d939cf30f3683436949bb4f335851622a
Change-Id: Idfa8625d939cf30f3683436949bb4f335851622a
Enforce for priv-apps with targetSdkVersion>=31.
This is the same restriction enforced on third party apps with
targetSdkVersion>=28 in Android 9.0. See:
https://developer.android.com/about/versions/pie/android-9.0-changes-28#per-app-selinux
This change allows selinux to better enforce the application sandbox
providing better defense-in-depth for priv-apps.
In particular it prevents apps running in the priv_app domain
from sharing their private data directory by granting
world-accessible unix permissions.
Bug: 142672293
Test: Build, boot, check for denials.
Change-Id: If2953eb990fdc24aaccf29be3394a9ee1f02185c
Apps signed with the media key share a UID (except
com.android.providers.media.module). However, some
run in the priv_app selinux context, and others run in
the mediaprovider context. That's a bug. Apps which share
a UID should always share an selinux domain. Assign all apps
with the seinfo=media to the mediaprovider selinux domain.
This moves the following packages from the priv_app to the
mediaprovider domain:
com.android.providers.downloads
com.android.providers.downloads.ui
com.android.mtp
com.android.soundpicker
Bug: 154614768
Test: atest CtsDownloadManagerApi28
Change-Id: I21bf68de525fff87c3a02aa59fba3a8d86be5324
All apps signed with the media key share a UID. However,
some run in the priv_app selinux context, and others run
in the mediaprovider context. That's a bug. Apps which share
a UID should always share an selinux domain. Assign all apps
with the seinfo=media to the mediaprovider selinux domain.
This moves the following packages from the priv_app to the
mediaprovider domain:
com.android.providers.downloads
com.android.providers.downloads.ui
com.android.mtp
com.android.soundpicker
Bug: 154614768
Test: atest CtsDownloadManagerApi28
Change-Id: I6f96142ef03101568abed670a0e32f952515a590
com.google.android.gms and com.google.android.gsf have a sharedUserId
but were being routed to two different domains:
com.google.android.gms 10145 0 /data/user/0/com.google.android.gms google:privapp:targetSdkVersion=10000
com.google.android.gsf 10145 0 /data/user/0/com.google.android.gsf google:privapp:targetSdkVersion=10000
This change routes them to the same domain: gmscore_app
Bug: 154597032
Test: TH
Change-Id: I0a309a687eb8608604cabf65b58763a1a3262153
This is a domain for the MediaProvider mainline module. The
MediaProvider process is responsible for managing external storage, and
as such should be able to have full read/write access to it. It also
hosts a FUSE filesystem that allows other apps to access said storage in
a safe way. Finally, it needs to call some ioctl's to set project quota
on the lower filesystem correctly.
Bug: 141595441
Test: builds, mediaprovider module gets the correct domain
Change-Id: I0d705148774a1bbb59c927e267a484cb5c44f548
Enforce new requirements on app with targetSdkVersion=30 including:
- No RTM_GETLINK on netlink route sockets.
Remove some of the repetitive descriptions in each untrusted_app_N.te
file, and instead refer to the description in
public/untrusted_app.te.
Bug: 141455849
Test: CtsSelinuxTargetSdkCurrentTestCases
Test: libcore.java.net.NetworkInterfaceTest#testGetNetworkInterfaces
Change-Id: I89553e48db3bc71f229c71fafeee9005703e5c0b
This reverts commit a1aa2210a9.
Reason for revert: Potential culprit for Bug b/148049462 - verifying through Forrest before revert submission
Change-Id: Ibe4fa1dee84defde324deca87d9de24a1cc2911a
Enforce new requirements on app with targetSdkVersion=30 including:
- No bind() on netlink route sockets.
- No RTM_GETLINK on netlink route sockets.
Remove some of the repetitive descriptions in each untrusted_app_N.te
file, and instead refer to the description in
public/untrusted_app.te.
Bug: 141455849
Test: CtsSelinuxTargetSdkCurrentTestCases
Change-Id: Iad4d142c0c13615b4710d378bc1feca4d125b6cc
* changes:
Revert "sepolicy: Permission changes for new wifi mainline module"
Revert "wifi_stack: Move to network_stack process"
Revert "sepolicy(wifi): Allow audio service access from wifi"
This change creates a gmscore_app domain for gmscore. The domain is
currently in permissive mode (for userdebug and eng builds), while we
observe the SELinux denials generated and update the gmscore_app rules
accordingly.
Bug: 142672293
Test: Flashed a device with this build and verified
com.google.android.gms runs in the gmscore_app domain. Tested different
flows on the Play Store app, e.g., create a new account, log in, update
an app, etc. and verified no new denials were generated.
Change-Id: Ie5cb2026f1427a21f25fde7e5bd00d82e859f9f3
This reverts commit 3aa1c1725e.
Reason for revert: Wifi services no longer plan to be a separate
APK/process for mainline. Will instead become a jar loaded from Apex.
Bug: 144722612
Test: Device boots up & connects to wifi networks
Change-Id: Ifa33dae971dccfd5d14991727e2f27d2398fdc74
This reverts commit 1086c7d71d.
Reason for revert: Wifi services no longer plan to be a separate
APK/process for mainline. Will instead become a jar loaded from Apex.
Bug: 144722612
Test: Device boots up & connects to wifi networks
Change-Id: I69ccc6afbe15db88f516cdc64e13d8cfdb0c743c
This change adds a rule for com.android.permissioncontroller to run in
the previously defined permissioncontroller_app.
com.android.permissioncontroller would require similar permissions to
com.google.android.permissioncontroller.
Bug: 142672293
Test: Green builds
Change-Id: I92e7175526380c0711f52fafe8d1f8d9531d07f8
This creates a new vzwomatrigger_app domain. The domain is
currently in permissive mode (for userdebug and eng builds), while we
observe the SELinux denials generated and update permissions.
Bug: 142672293
Test: Build, flash, boot successfully
Change-Id: I552df772b66e8e7edb1ccee754d1ea8dd1acece0
Relax the requirement to have both seinfo and name specified for
privapps. The original reason for requiring both was because, normally,
a package can only be uniquely specified by both name and signature,
otherwise package squatting could occur. However, privapps are
pre-installed, so the concerns about the potential for package squatting
are eliminated. This change will drastically simplify sepolicy
configuration for priv-apps.
Bug: 142672293
Test: Flashed a device with this build and verified
com.google.android.permissioncontroller still runs in the
permissioncontroller_app domain.
Change-Id: I5bb2bf84b9db616c4492bd1402550821c70fdd07
This creates an SELinux domain for permissioncontroller and moves it out of the
priv_app SELinux domain.
Bug: 142672293
Test: Flashed a device with this build and verified
com.google.android.permissioncontroller runs in the
permissioncontroller_app domain.
Change-Id: Ieb2e4cb806d18aaeb2e5c458e138975d1d5b64fe
The wifi stack APK will run inside the network_stack process. So, move
the sepolicy rules for wifi stack inside the network stack rules.
Bug: 135691051
Test: Manual tests
- manual connect to wifi networks
- Remove networks
Test: Will send for ACTS wifi regression testing
Change-Id: I9d5da80852f22fa1d12b2dbbc76b9e06c1275310
(cherry-picked from b83abf7af3df64e0d3c1b22548f2344b55aece28)
Move wifi services out of system_server into a separate APK/process.
Changes:
a) Created sepolicy for the new wifi apk.
b) The new APK will run with network_stack uid (eventually will be moved
to the same process).
Used 'audit2allow' tool to gather list of permissions required.
Note: The existing wifi related permissions in system_server is left
behind to allow the module to be loaded into system_server or
network_stack process depending on device configuration.
Bug: 113174748
Test: Device boots up and able to make wifi connection.
Test: Tested hotspot functionality.
Test: Ran WifiManagerTest & WifiSoftApTest ACTS tests locally.
Test: Will send for wifi regression tests.
Change-Id: Id19643a235bf0c28238f2729926b893ac2025b97
(cherry-picked from c7aa90091e6bec70a31a643cc4519a9a86fb0b38)
After moving IpMemoryStore service to network stack module(aosp/906907),
the following untracked SELinux denials are observed on boot.
W id.networkstack: type=1400 audit(0.0:63): avc: denied { write } for
name="com.android.networkstack" dev="sda13" ino=704810
scontext=u:r:network_stack:s0:c49,c260,c512,c768
tcontext=u:object_r:system_data_file:s0 tclass=dir permissive=0
Add radio_data_file type for network stack user configuration and
relevant permission to allow access to its data, as the network stack
is a privileged app.
Test: m -j passed
Change-Id: I6eab528714df6a17aae0cb546dcc3ad4bb21deea
Update the seinfo to the new network_stack seinfo, as the network stack
is now using its own certificate.
Remove the hard-coded package name, which may differ depending on
devices, and specify (uid, signature, priv-app) instead.
Bug: 124033493
Test: m
Change-Id: If3bbc21cf83f5d17406e9615833ee43011c9c9bc
Add some missing fields, document undocumented fields, update
precedence rules, and attempt to give slightly more context.
Test: Builds
Change-Id: Id106ebe3aa6c18697db82a775cc54ed07b6c1a57
The application zygote is a new sort of zygote process that is a
child of the regular zygote. Each application zygote is tied to the
application for which it's launched. Once it's started, it will
pre-load some of the code for that specific application, much like
the regular zygote does for framework code.
Once the application zygote is up and running, it can spawn
isolated service processes that run in the isolated_app domain. These
services can then benefit from already having the relevant
application code and data pre-loaded.
The policy is largely the same as the webview_zygote domain,
however there are a few crucial points where the policy is different.
1) The app_zygote runs under the UID of the application that spawned
it.
2) During app_zygote launch, it will call a callback that is
controlled by the application, that allows the application to
pre-load code and data that it thinks is relevant.
Especially point 2 is imporant: it means that untrusted code can run
in the app_zygote context. This context is severely limited, and the
main concern is around the setgid/setuid capabilities. Those conerns
are mitigated by installing a seccomp filter that only allows
setgid/setuid to be called in a safe range.
Bug: 111434506
Test: app_zygote can start and fork children without denials.
Change-Id: I1cc49ee0042d41e5ac6eb81d8f8a10ba448d4832
runas_app domain is used by lldb/ndk-gdb/simpleperf to debug/profile
debuggable apps. But it misses permissions to ptrace app processes and
read /proc/<app_pid> directory.
Bug: none
Test: build and boot marlin.
Test: run lldb and simpleperf on apps with target sdk version 24-29.
Change-Id: I9e6f940ec81a8285eae8db3b77fb1251a25dedd0
The networking stack app hosts services that used to be in the system
server (IpClient, NetworkMonitor for now), but in a different process to
be packaged as a mainline module.
Test: booted, verified networking stack working when in app
Change-Id: I300a556f51b35c17378af961cea1ec937444e597
Calling execve() on files in an app's home directory isn't allowed
for targetApi >=29. But this is needed by simpleperf to profile
a debuggable app via run-as.
So workaround it by adding runas_app domain, which allows running
app data file. And add a rule in seapp_contexts to use runas_app
domain for setcontext requests from run-as.
Bug: 118737210
Test: boot marlin and run CtsSimpleperfTestCases.
Change-Id: I5c3b54c95337d6d8192861757b858708174ebfd5
Create a transient SELinux domain where system_server can perform
certain JIT setup. The idea is that system_server will start in the
system_server_startup domain, setup certain JIT pages, then perform a
one-way transition into the system_server domain. From that point,
further JITing operations are disallowed.
Bug: 62356545
Test: device boots, no permission errors
Change-Id: Ic55b2cc5aba420ebcf62736622e08881a4779004
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
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.
Commit 23c9d91b46 introduced a new type
called privapp_data_file and added rules necessary to preserve
compatibility. However, that change did not relabel any existing files,
so effectively the change was a no-op.
This change performs the switch, relabeling priv-app's /data/data files
from app_data_file to privapp_data_file. Due to the compatibility rules
added in 23c9d91b46, there should be no
noticeable effect from this change.
This change was originally submitted as
4df57822fc. However, it was reverted in
cdc6649acc due to a different labeling
bug. That bug has been fixed, and we can reapply this change.
Test: Factory reset and boot - no problems on fresh install.
Test: Upgrade to new version and test. No compatibility problems on
filesystem upgrade.
Bug: 112357170
There is a problem with on-disk labeling of files created by secondary
dex background compilation which is causing unexpected denials to show
up. Restore the old labeling until we are able to fix the underlying
problem.
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".
This reverts commit 4df57822fc.
Bug: 112357170
Test: policy compiles
Change-Id: I38ba75c92c9c46e6a1fdbc02e3dc80c63adccaa8
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.
Commit 23c9d91b46 introduced a new type
called privapp_data_file and added rules necessary to preserve
compatibility. However, that change did not relabel any existing files,
so effectively the change was a no-op.
This change performs the switch, relabeling priv-app's /data/data files
from app_data_file to privapp_data_file. Due to the compatibility rules
added in 23c9d91b46, there should be no
noticeable effect from this change.
Test: Factory reset and boot - no problems on fresh install.
Test: Upgrade to new version and test. No compatibility problems on
filesystem upgrade.
Merged-In: I9a476726bf01f4bcc7952d11fd57dba803a9fd8d
Change-Id: I23a26cd3906fc43cbd225c05c3a2abd3cab8bd06
