Android's native bridge functionality allows an Android native
app written on one CPU architecture to run on a different architecture.
For example, Android ARM apps may run on an x86 CPU.
To support this, the native bridge functionality needs to replace
/proc/cpuinfo with the version from /system/lib/<ISA>/cpuinfo
using a bind mount. See commit ab0da5a9a6860046619629b8e6b83692d35dff86
in system/core.
This change:
1) Creates a new label proc_cpuinfo, and assigns /proc/cpuinfo
that label.
2) Grants read-only access to all SELinux domains, to avoid
breaking pre-existing apps.
3) Grants zygote mounton capabilities for that file, so zygote
can replace the file as necessary.
Addresses the following denial:
avc: denied { mounton } for path="/proc/cpuinfo" dev="proc" ino=4026532012 scontext=u:r:zygote:s0 tcontext=u:object_r:proc:s0 tclass=file
Bug: 17671501
(cherry picked from commit 2de02877a3)
Change-Id: I2c2366bee4fe365288d14bca9778d23a43c368cb
Android's native bridge functionality allows an Android native
app written on one CPU architecture to run on a different architecture.
For example, Android ARM apps may run on an x86 CPU.
To support this, the native bridge functionality needs to replace
/proc/cpuinfo with the version from /system/lib/<ISA>/cpuinfo
using a bind mount. See commit ab0da5a9a6860046619629b8e6b83692d35dff86
in system/core.
This change:
1) Creates a new label proc_cpuinfo, and assigns /proc/cpuinfo
that label.
2) Grants read-only access to all SELinux domains, to avoid
breaking pre-existing apps.
3) Grants zygote mounton capabilities for that file, so zygote
can replace the file as necessary.
Addresses the following denial:
avc: denied { mounton } for path="/proc/cpuinfo" dev="proc" ino=4026532012 scontext=u:r:zygote:s0 tcontext=u:object_r:proc:s0 tclass=file
Bug: 17671501
Change-Id: Ib70624fba2baeccafbc0a41369833f76b976ee20
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
Add levelFrom=user to the entries for apps other than those
that run in the predefined platform UIDs (e.g. system, nfc, radio, ...).
This causes libselinux to assign a per-user category set computed from
the user ID portion of the Linux UID to each app process and its
/data/data/<pkgdir> or /data/user/N/<pkgdir> directory. These
per-user category sets can be seen in the last field of ps -Z output for
apps and ls -Z /data/data or /data/user/N output for the package
directories.
With this applied, apps running on behalf of one user cannot read
or write files created by apps running on behalf of another user,
even if the file is world-readable or -writable. Similar isolation is
enforced over process interactions (including /proc/pid file access),
local socket communications, and System V IPC, as expressed in the
set of constraints defined in the mls configuration. At present,
Binder IPC is not restricted by the mls configuration; if desired,
there is a constraint in the configuration that can be uncommented
to also apply isolation on direct binder IPC, although communication
will still be possible indirectly via the system_server.
Bug: 13507660
Change-Id: I3972f846ff5e7363799ba521f1258d662b18d64e
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
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
Introduce separate types for the userdata and cache block
devices so that we can assign them and allow access to them
in device-specific policy without allowing access to any other
block device (e.g. system). These types will only be used if
assigned to device node paths in the device-specific file_contexts
configuration. Otherwise, this change will have no impact - the
userdata and cache block devices will continue to default to block_device
type.
To avoid breakage when these new types are assigned to the userdata
block device, allow access by vold and uncrypt, but auditallow
these accesses to confirm that these are required.
Change-Id: I99d24f06506f51ebf1d186d9c393b3cad60e98d7
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
The kernel driver has been deprecated by the new userspace
driver. Don't continue to allow access to the old driver.
Maintain the labeling on /dev/log/* for now, just in case.
Bug: 13505761
Change-Id: Ibf8ef3af6274ede4262aada9222eaf63f63307b4
Enable labeling apps differently depending on whether they
are running for the primary user / owner or for a secondary user.
Change-Id: I37aa5b183a7a617cce68ccf14510c31dfee4e04d
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
dumpstate and lmkd need to act on apps running at any level.
Various file types need to be writable by apps running at any
level.
Change-Id: Idf574d96ba961cc110a48d0a00d30807df6777ba
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
On 64 bit systems, it's necessary to read the /system/bin executables
elf header to determine if it's a 32 bit or 64 bit executable to
contact the correct debuggerd service.
Bug: 17487122
(cherry picked from commit 04f3d79077)
Change-Id: Ib7835ffac1811a5aef54a250689287c1666720ef
On 64 bit systems, it's necessary to read the /system/bin executables
elf header to determine if it's a 32 bit or 64 bit executable to
contact the correct debuggerd service.
Bug: 17487122
Change-Id: Ica78aa54e5abbb051924166c6808b79b516274fe
