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
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
Text relocation support was removed from the linker for apps targeting
API >= 23. See
https://android.googlesource.com/platform/bionic/+/master/android-changes-for-ndk-developers.md#text-relocations-enforced-for-api-level-23
However, the security policy was not updated to remove the execmod
permission at that time, since we didn't have support for targeting
SELinux policies to API versions.
Remove execmod permissions for apps targeting API 26 or greater. The
linker support was removed, so it's pointless to keep around the SELinux
permissions.
Retain execmod support for apps targeting API 25 or lower. While in
theory we could remove support for API 23-25, that would involve the
introduction of a new SELinux domain (and the associated rule
explosion), which I would prefer to avoid.
This change helps protect application executable code from modification,
enforcing W^X properties on executable code pages loaded from files.
https://en.wikipedia.org/wiki/W%5EX
Test: auditallow rules were added and nothing triggered for apps
targeting API >= 26. Code compiles and device boots.
Bug: 111544476
Change-Id: Iab9a0bd297411e99699e3651c110e57eb02a3a41
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
Remove the exemptions for untrusted apps and broaden the neverallow so
they can't be reinstated. Modifying executable pages is unsafe. Text
relocations are not supported.
Bug: 111544476
Test: Builds.
Change-Id: Ibff4f34d916e000203e38574bb063513e4428bb7
This is so we can get data on which apps are actually doing this.
Bug: 111544476
Test: Device boots. No audits seen on test device.
Change-Id: I5f72200ed8606775904d353c4d3d790373fe7dea
The recommended solution is to not access encrypted storage until
after the ACTION_USER_UNLOCKED intent is delivered.
Test: build
Fixes: 72811052
Fixes: 72550646
Change-Id: I80eb743e26047b7864de983c5a46c28b6f753a59
Files in /proc/net leak information. This change is the first step in
determining which files apps may use, whitelisting benign access, and
otherwise removing access while providing safe alternative APIs.
To that end, this change:
* Introduces the proc_net_type attribute which will assigned to any
new SELinux types in /proc/net to avoid removing access to privileged
processes. These processes may be evaluated later, but are lower
priority than apps.
* Labels /proc/net/{tcp,tcp6,udp,udp6} as proc_net_vpn due to existing
use by VPN apps. This may be replaced by an alternative API.
* Audits all other proc/net access for apps.
* Audits proc/net access for other processes which are currently
granted broad read access to /proc/net but should not be including
storaged, zygote, clatd, logd, preopt2cachename and vold.
Bug: 9496886
Bug: 68016944
Test: Boot Taimen-userdebug. On both wifi and cellular: stream youtube
navigate maps, send text message, make voice call, make video call.
Verify no avc "granted" messages in the logs.
Test: A few VPN apps including "VPN Monster", "Turbo VPN", and
"Freighter". Verify no logspam with the current setup.
Test: atest CtsNativeNetTestCases
Test: atest netd_integration_test
Test: atest QtaguidPermissionTest
Test: atest FileSystemPermissionTest
Change-Id: I7e49f796a25cf68bc698c6c9206e24af3ae11457
Merged-In: I7e49f796a25cf68bc698c6c9206e24af3ae11457
(cherry picked from commit 087318957f)
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 is a partial cherry pick of commit 6231b4d9
'Enforce per-app data protections for targetSdk 28+'.
Untrusted_app_27 remains unreachable, but it's existence
prevents future merge conflicts.
Bug: 63897054
Test: build/boot aosp_walleye-userdebug
Change-Id: I64b013874fe87b55f47e817a1279e76ecf86b7c0
Merged-In: I64b013874fe87b55f47e817a1279e76ecf86b7c0
(cherry picked from commit 6231b4d9fc)
This change will allow traceur to pass a file descriptor to another app
in order to allow that app to process trace data files. E.g. in the use
case that someone would like to email the traces they collected and pass
the trace data files to gmail, this will now be permitted.
Bug:68126425
Test: Traceur can pass fd's to untrusted apps for processing
Change-Id: If0507b5d1f06fd8400e04bd60e06a44153dc59b7
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
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
The typical use case is where vendor apps which run as untrusted apps
use libraries that are packaged withing the apk
Bug: 37753883
Test: Tested by runnig pre-installed app that packages a library from
/vendor/app
Change-Id: I445144e37e49e531f4f43b13f34d6f2e78d7a3cf
Signed-off-by: Sandeep Patil <sspatil@google.com>
Rules defined in utrusted_app_all do not apply to all untrusted apps,
update the comments to reflect that.
Test: builds
Change-Id: I6f064bd93c13d8341128d941be34fdfaa0bec5da
