Users can pick files from vfat devices through the Storage Access
Framework, which are returned through ParcelFileDescriptors. Grant
apps write access to those files. (Direct access to the files on
disk is still controlled through normal filesystem permissions.)
avc: denied { write } for pid=3235 comm="Binder_1" path=2F6D6E742F6D656469615F72772F373243322D303446392F6D656F772F6D79206469722F706963322E706E67 dev="sdb1" ino=87 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:vfat:s0 tclass=file
Bug: 19993667
Change-Id: I24b4d8826f0a35825b2abc63d1cfe851e1c1bfe9
Google Breakpad (crash reporter for Chrome) relies on ptrace
functionality. Without the ability to ptrace, the crash reporter
tool is broken.
Addresses the following denial:
type=1400 audit(1428619926.939:1181): avc: denied { ptrace } for pid=10077 comm="CrRendererMain" scontext=u:r:isolated_app:s0:c512,c768 tcontext=u:r:isolated_app:s0:c512,c768 tclass=process permissive=0
This reverts commit e9623d8fe6.
Bug: 20150694
Bug: https://code.google.com/p/chromium/issues/detail?id=475270
Change-Id: I1727c6a93f10ea6db877687a8f81ec789f9e501f
On debuggable builds, system_server can request app heap dumps
by running something similar to the following commands:
% adb shell am set-watch-heap com.android.systemui 1048576
% adb shell dumpsys procstats --start-testing
which will dump the app's heap to /data/system/heapdump. See
framework/base commit b9a5e4ad30c9add140fd13491419ae66e947809d.
Allow this behavior.
Addresses the following denial:
avc: denied { write } for path="/data/system/heapdump/javaheap.bin" dev="dm-0" ino=150747 scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:system_data_file:s0 tclass=file permissive=0
Bug: 20073185
Change-Id: I4b925033a5456867caf2697de6c2d683d0743540
Apps, shell and adbd should all have identical access to external
storage. Also document where we have files and/or symlinks.
Bug: 20055945
Change-Id: I133ffcf28cc3ccdb0541aba18ea3b9ba676eddbe
Executing dumpsys meminfo over the console shell requires that output go to the
console_device. meminfo passes a fd to each applicaiton thread so that it can
do this in IApplicationThread.dumpMemInfo(). Allow use of this fd.
Addresses the following denial:
type=1400 audit(1426793987.944:4224): avc: denied { read write } for pid=1809 comm="Binder_4" path="/dev/console" dev="tmpfs" ino=5684 scontext=u:r:platform_app:s0 tcontext=u:object_r:console_device:s0 tclass=chr_file
Bug: 17135173
Change-Id: Id5340a1fb3c8dbf41bda427720c4a0047bc557fc
This was rendered obsolete when SELinuxDomainTest was ported
to SELinuxHostTest and only makes sense if allowing search
to domain:dir and { open read } to domain:file in order to
open the /proc/pid/attr/current files in the first place.
SELinux applies a further :process getattr check when
reading any of the /proc/pid/attr/* files for any process
other than self, which is no longer needed by app domains to
pass CTS.
Change-Id: Iff1e601e1268d4d77f64788d733789a2d2cd18cc
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
There were a few instances where allow rules were appended
after the neverallow rules stanza in the .te file. Also
there were some regular allow rules inserted into the CTS-specific
rules section of app.te. Just move the rules as appropriate.
Should be no change in policy.
Change-Id: Iec76f32d4b531d245bbf5dd9f621a71ff5c71f3e
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
isolated apps should only be able to access 2 services.
Remove access permissions for services inappropriately added,
and add a neverallow rule to prevent regressions.
Change-Id: I2783465c4a22507849b2a64894fb76690a27bc01
Revert the tightening of /proc/net access. These changes
are causing a lot of denials, and I want additional time to
figure out a better solution.
Addresses the following denials (and many more):
avc: denied { read } for comm="SyncAdapterThre" name="stats" dev="proc" ino=X scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:proc_net:s0 tclass=file
avc: denied { read } for comm="facebook.katana" name="iface_stat_fmt" dev="proc" ino=X scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:proc_net:s0 tclass=file
avc: denied { read } for comm="IntentService[C" name="if_inet6" dev="proc" ino=X scontext=u:r:untrusted_app:s0:c512,c768 tcontext=u:object_r:proc_net:s0 tclass=file
avc: denied { read } for comm="dumpstate" name="iface_stat_all" dev="proc" ino=X scontext=u:r:dumpstate:s0 tcontext=u:object_r:proc_net:s0 tclass=file
This reverts commit 0f0324cc82
and commit 99940d1af5
Bug: 9496886
Bug: 19034637
Change-Id: I436a6e3638ac9ed49afbee214e752fe2b0112868
Without this change, any selinux warning you might get when running
dumpstate from init do not show up when running from the shell
as root. This change makes them run the same.
Change-Id: I6b74e0f6f48f47952a2dbe7728b1853008f60dbb
Relax the neverallow netlink restrictions for app domains.
In particular, some non-AOSP app domains may use netlink sockets
to communicate with a kernel driver.
Continue to neverallow generic netlink sockets for untrusted_app.
The intention here is that only app domains which explicitly need
this functionality should be able to request it.
This change does not add or remove any SELinux rules. Rather, it
just changes SELinux compile time assertions, as well as allowing
this behavior in CTS.
Modify other neverallow rules to use "domain" instead of "self".
Apps shouldn't be able to handle netlink sockets, even those
created in other SELinux domains.
Change-Id: I40de0ae28134ce71e808e5ef4a39779b71897571
Chrome team recommends reverting this patch and introducing
it into a future version of Android, to avoid potential
compatibility issues.
This reverts commit 9de62d6ffe.
Bug: 17471434
Bug: 18609318
Change-Id: I9adaa9d0e4cb6a592011336e442e9d414dbac470
SELinux domains wanting read access to /proc/net need to
explicitly declare it.
TODO: fixup the ListeningPortsTest cts test so that it's not
broken.
Bug: 9496886
Change-Id: Ia9f1214348ac4051542daa661d35950eb271b2e4
Only allow it to read/write/stat already open app data files
received via Binder or local socket IPC.
Change-Id: Ie66f240e109410a17aa93d9d5dea4c2b87d47009
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
This is causing the version of Chrome in Android's tree to crash. The
version of Chrome in Android's tree does not have the following patch:
https://codereview.chromium.org/630123003
Until Chrome updates the version in Android's tree, we need to revert.
Works around the following denials:
audit(0.0:19): avc: denied { search } for name="com.android.chrome" dev="mmcblk0p28" ino=1474658 scontext=u:r:isolated_app:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=dir
audit(0.0:20): avc: denied { getattr } for path="/data/data/com.android.chrome" dev="mmcblk0p28" ino=1474658 scontext=u:r:isolated_app:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=dir
audit(0.0:21): avc: denied { getattr } for path="/data/data/com.android.chrome" dev="mmcblk0p28" ino=1474658 scontext=u:r:isolated_app:s0:c512,c768 tcontext=u:object_r:app_data_file:s0:c512,c768 tclass=dir
This reverts commit 669a977303.
Bug: 18006219
Change-Id: Id44137ec6a0dfe4a597b34ab3dad9e3feecc2a5e
Currently, zygote spawned apps are prohibited from modifying GPS
data files. If someone tries to allow GPS access to any app domain,
it generates a compile time / CTS exception.
Relax the rules slightly for system_app. These apps run with UID=system,
and shouldn't be banned from handling gps data files.
This change doesn't add or remove any SELinux rules. Rather, it just
relaxes a compile time assertion, allow partners to create SELinux
rules allowing the access if they desire.
(cherrypick from commit 480374e4d0)
Bug: 18021422
Change-Id: Iad0c6a3627efe129246e2c817f6f71d2735eba93
Currently, zygote spawned apps are prohibited from modifying GPS
data files. If someone tries to allow GPS access to any app domain,
it generates a compile time / CTS exception.
Relax the rules slightly for system_app. These apps run with UID=system,
and shouldn't be banned from handling gps data files.
This change doesn't add or remove any SELinux rules. Rather, it just
relaxes a compile time assertion, allow partners to create SELinux
rules allowing the access if they desire.
Bug: 18021422
Change-Id: Iad0c6a3627efe129246e2c817f6f71d2735eba93
Migrators should be allowed to write to /data/misc/keychain in order
to remove it. Similarly /data/misc/user should be writable by system
apps.
TODO: Revoke zygote's rights to read from /data/misc/keychain on
behalf of some preloaded security classes.
Bug: 17811821
Change-Id: I9e9c6883cff1dca3755732225404909c16a0e547
Only allow it to read/write/stat already open app data files
received via Binder or local socket IPC.
Change-Id: I3c096607a74fd0f360d41f3e6f06535ca00c58ec
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Apps should be able to read the contents of mounted OBBs.
Steps to reproduce:
1) Install com.namcobandaigames.soulcaliburgp (SoulCalibur)
2) Attempt to run the app.
Expected:
App runs successfully.
Actual:
App crashes. See denials below.
This can also be reproduced by running the newly introduced CTS
test in I2018b63b0236ce6b5aee4094e40473315b1948c3
Addresses the following denials:
avc: denied { read } for pid=4133 comm="roidJUnitRunner" name="test1.txt" dev="loop0" ino=23 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:vfat:s0 tclass=file
avc: denied { open } for pid=4133 comm="roidJUnitRunner" name="test1.txt" dev="loop0" ino=23 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:vfat:s0 tclass=file
avc: denied { getattr } for pid=4133 comm="roidJUnitRunner" path="/mnt/obb/f73da56689d166b5389d49ad31ecbadb/test1.txt" dev="loop0" ino=23 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:vfat:s0 tclass=file
avc: denied { search } for name="/" dev="loop0" ino=1 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:vfat:s0 tclass=dir permissive=0
(cherrypick of commit 62083414a4)
Bug: 17633509
Change-Id: I49b722b24c1c7d9ab084ebee7c1e349d8d660ffa
Apps should be able to read the contents of mounted OBBs.
Steps to reproduce:
1) Install com.namcobandaigames.soulcaliburgp (SoulCalibur)
2) Attempt to run the app.
Expected:
App runs successfully.
Actual:
App crashes. See denials below.
This can also be reproduced by running the newly introduced CTS
test in I2018b63b0236ce6b5aee4094e40473315b1948c3
Addresses the following denials:
avc: denied { read } for pid=4133 comm="roidJUnitRunner" name="test1.txt" dev="loop0" ino=23 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:vfat:s0 tclass=file
avc: denied { open } for pid=4133 comm="roidJUnitRunner" name="test1.txt" dev="loop0" ino=23 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:vfat:s0 tclass=file
avc: denied { getattr } for pid=4133 comm="roidJUnitRunner" path="/mnt/obb/f73da56689d166b5389d49ad31ecbadb/test1.txt" dev="loop0" ino=23 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:vfat:s0 tclass=file
avc: denied { search } for name="/" dev="loop0" ino=1 scontext=u:r:untrusted_app:s0 tcontext=u:object_r:vfat:s0 tclass=dir permissive=0
Bug: 17633509
Change-Id: I49b722b24c1c7d9ab084ebee7c1e349d8d660ffa
During factory provisioning, some manufacturers may need to pull files
from /factory (label efs_file and bluetooth_efs_file) to collect
device specific identifiers such as the mac address, using commands
similar to the following:
adb shell cat /factory/ssn
adb shell cat /factory/bt/bd_addr.conf
adb shell cat /factory/wifi/mac.txt
adb shell cat /factory/60isn
read-only access to these files is currently disallowed by a
neverallow rule. Relax the rules to allow read-only access to the
shell user if desired.
No new SELinux rules are added or deleted by this change. This is
only a relaxation in what's allowed for vendor specific policy.
Bug: 17600278
(cherry picked from commit 200a9f0e20)
Change-Id: I2e277b1068a35cc06e0973df994ec3a49f2c26e7
During factory provisioning, some manufacturers may need to pull files
from /factory (label efs_file and bluetooth_efs_file) to collect
device specific identifiers such as the mac address, using commands
similar to the following:
adb shell cat /factory/ssn
adb shell cat /factory/bt/bd_addr.conf
adb shell cat /factory/wifi/mac.txt
adb shell cat /factory/60isn
read-only access to these files is currently disallowed by a
neverallow rule. Relax the rules to allow read-only access to the
shell user if desired.
No new SELinux rules are added or deleted by this change. This is
only a relaxation in what's allowed for vendor specific policy.
Bug: 17600278
Change-Id: I13f33f996c077918dce70a5cff31a87eac436678
Netlink uevent sockets are used by the kernel to inform userspace
when certain events occur, for example, when new hardware is added
or removed. This allows userspace to take some action based on those
messages.
Relax the neverallow rule for NETLINK_KOBJECT_UEVENT sockets.
Certain device specific app domains, such as system_app, may have a
need to receive messages from this socket type.
Continue to neverallow NETLINK_KOBJECT_UEVENT sockets for untrusted_app.
These sockets have been the source of rooting attacks in Android
in the past, and it doesn't make sense to expose this to untrusted_apps.
No new SELinux rules are introduced by this change. This is an
adjustment of compile time assertions only.
Bug: 17525863
(cherry picked from commit 642b80427e)
Change-Id: I35f3dc8b1ead9f427645a13fb202e760d1e68e64
Netlink uevent sockets are used by the kernel to inform userspace
when certain events occur, for example, when new hardware is added
or removed. This allows userspace to take some action based on those
messages.
Relax the neverallow rule for NETLINK_KOBJECT_UEVENT sockets.
Certain device specific app domains, such as system_app, may have a
need to receive messages from this socket type.
Continue to neverallow NETLINK_KOBJECT_UEVENT sockets for untrusted_app.
These sockets have been the source of rooting attacks in Android
in the past, and it doesn't make sense to expose this to untrusted_apps.
No new SELinux rules are introduced by this change. This is an
adjustment of compile time assertions only.
Bug: 17525863
Change-Id: I3e538dc8096dc23b9678bcd20e3c1e742c21c967
Also enable global reading of kernel policy file. Motivation for this is to
allow read access to the kernel version of the binary selinux policy.
Bug: 17288791
Change-Id: I1eefb457cea1164a8aa9eeb7683b3d99ee56ca99
