Chrome renderer processes dlopen() a shared library from
gmscore. Open and read on app data file is already allowed,
but execute isn't, so the dlopen() fails. This is a regression
from K, where the dlopen succeeded.
Longer term, there's questions about whether this is appropriate
behavior for an isolated app. For now, allow the behavior.
See the discussion in b/15902433 for details.
Addresses the following denial:
I/auditd ( 5087): type=1400 audit(0.0:76): avc: denied { execute } for comm="CrRendererMain" path="/data/data/com.google.android.gms/files/libAppDataSearchExt_armeabi_v7a.so" dev="mmcblk0p28" ino=83196 scontext=u:r:isolated_app:s0 tcontext=u:object_r:app_data_file:s0 tclass=file
Bug: 15902433
Change-Id: Ie98605d43753be8c31a6fe510ef2dde0bdb52678
Coalesce a number of allow rules replicated among multiple
app domains.
Get rid of duplicated rules already covered by domain, appdomain,
or platformappdomain rules.
Split the platformappdomain rules to their own platformappdomain.te
file, document them more fully, and note the inheritance in each
of the relevant *_app.te files.
Generalize isolated app unix_stream_socket rules to all app domains
to resolve denials such as:
avc: denied { read write } for pid=11897 comm="Binder_2" path="socket:[203881]" dev="sockfs" ino=203881 scontext=u:r:release_app:s0 tcontext=u:r:untrusted_app:s0 tclass=unix_stream_socket
avc: denied { getattr } for pid=11990 comm=4173796E635461736B202334 path="socket:[203881]" dev="sockfs" ino=203881 scontext=u:r:release_app:s0 tcontext=u:r:untrusted_app:s0 tclass=unix_stream_socket
avc: denied { getopt } for pid=11990 comm=4173796E635461736B202334 scontext=u:r:release_app:s0 tcontext=u:r:untrusted_app:s0 tclass=unix_stream_socket
avc: denied { read write } for pid=6890 comm="Binder_10" path="socket:[205010]" dev="sockfs" ino=205010 scontext=u:r:release_app:s0 tcontext=u:r:media_app:s0 tclass=unix_stream_socket
avc: denied { getattr } for pid=11990 comm=4173796E635461736B202334 path="socket:[205010]" dev="sockfs" ino=205010 scontext=u:r:release_app:s0 tcontext=u:r:media_app:s0 tclass=unix_stream_socket
avc: denied { getopt } for pid=11990 comm=4173796E635461736B202334 scontext=u:r:release_app:s0 tcontext=u:r:media_app:s0 tclass=unix_stream_socket
Change-Id: I770d7d51d498b15447219083739153265d951fe5
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
There is some overlap between socket rules in app.te and the net.te rules,
but they aren't quite identical since not all app domains presently include
the net_domain() macro and because the rules in app.te allow more permissions
for netlink_route_socket and allow rawip_socket permissions for ping.
The current app.te rules prevent one from ever creating a non-networked app
domain. Resolve this overlap by:
1) Adding the missing permissions allowed by app.te to net.te for
netlink_route_socket and rawip_socket.
2) Adding net_domain() calls to all existing app domains that do not already
have it.
3) Deleting the redundant socket rules from app.te.
Then we'll have no effective change in what is allowed for apps but
allow one to define app domains in the future that are not allowed
network access.
Also cleanup net.te to use the create_socket_perms macro rather than *
and add macros for stream socket permissions.
Change-Id: I6e80d65b0ccbd48bd2b7272c083a4473e2b588a9
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
From the commit that added these rules, this appears to have been
an artifact of having dumpstate running in the init domain.
Change-Id: Iec2b9c3f5673d0e2cce9a0bf297e23555c423e87
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
r_dir_file(appdomain, isolated_app) was in both app.te and isolated_app.te;
delete it from isolated_app.te.
binder_call(appdomain, isolated_app) is a subset of binder_call(appdomain, appdomain); delete it.
Change-Id: I3fd90ad9c8862a0e4dad957425cbfbc9fa97c63f
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
For additional context-
The denials related to init_tmpfs are of the form:
denied { read } for pid=12315 comm=""dboxed_process0"" path=2F6465762F6173686D656D2F64616C76696B2D68656170202864656C6574656429 dev=""tmpfs"" ino=9464 scontext=u:r:isolated_app:s0 tcontext=u:object_r:init_tmpfs:s0 tclass=file
(the path above is "/dev/ashmem/dalvik-heap (deleted)")
The denials related to executing things from the dalvik cache are of the form:
enied { execute } for pid=3565 comm=""dboxed_process0"" path=""/data/dalvik-cache/system@app@Chrome.apk@classes.dex"" dev=""mmcblk0p28"" ino=105983 scontext=u:r:isolated_app:s0 tcontext=u:object_r:dalvikcache_data_file:s0 tclass=file
The denials related to isolated_app and the init socket are:
denied { getattr } for pid=3824 comm=""Binder_2"" path=""socket:[14059]"" dev=""sockfs"" ino=14059 scontext=u:r:isolated_app:s0 tcontext=u:r:init:s0 tclass=unix_stream_socket
The getopt denials for the aforementioned socket are:
denied { getopt } for pid=3824 comm=""Binder_2"" path=""/dev/socket/dumpstate"" scontext=u:r:isolated_app:s0 tcontext=u:r:init:s0 tclass=unix_stream_socket
Change-Id: I3c57702e2af5a779a7618da9aa40930e7f12ee49
OTAs aren't properly labeling /system, which is causing SELinux
breakage. Temporarily put isolated_app.te and untrusted_app.te
into permissive.
Bug: 9878561
Change-Id: Icaf674ad6b3d59cbca3ae796c930c98ab67cae9c
This is my first attempt at creating an enforcing SELinux domain for
apps, untrusted_apps, and isolated_apps. Much of these rules are based on the
contents of app.te as of commit 11153ef349
with extensive modifications, some of which are included below.
* Allow communication with netd/dnsproxyd, to allow netd to handle
dns requests
* Allow binder communications with the DNS server
* Allow binder communications with surfaceflinger
* Allow an app to bind to tcp/udp ports
* Allow all domains to read files from the root partition, assuming
the DAC allows access.
In addition, I added a bunch of "neverallow" rules, to assert that
certain capabilities are never added.
This change has a high probability of breaking someone, somewhere.
If it does, then I'm happy to fix the breakage, rollback this change,
or put untrusted_app into permissive mode.
Change-Id: I83f220135d20ab4f70fbd7be9401b5b1def1fe35
app.te covers a lot of different apps types (platform_app, media_app,
shared_app, release_app, isolated_app, and untrusted_app), all
of which are going to have slightly different security policies.
Separate the different domains from app.te. Over time, these
files are likely to grow substantially, and mixing different domain types
is a recipe for confusion and mistakes.
No functional change.
Change-Id: Ida4e77fadb510f5993eb2d32f2f7649227edff4f
