Linux kernel 4.14+ SELinux starts explicit map
permission check for file mmap operations. Add this
permission to system_server for data file access,
which is used in scenario such as "adb install" of
APK's.
test: no longer see SELinux map denial on "adb install"
Change-Id: Id6016dd0b3f15dfdb0f02509ea812dee61ac78ed
Allow lmkd write access to sys.lmk. properties to be able to set
sys.lmk.minfree_levels.
Bug: 111521182
Test: getprop sys.lmk.minfree_levels returns value set by lmkd
Change-Id: I86ff11d75917966857d3a76876a56799bb92a5ad
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
/cache/overlay directory in support of overlayfs mounts on userdebug
and eng devices. Overlayfs in turn can be capable of supporting
adb remount for read-only or restricted-storage filesystems like
squashfs or right-sized (zero free space) system partitions
respectively.
Test: compile
Bug: 109821005
Bug: 110985612
Change-Id: I3ece03886db7cc97f864497cf93ec6c6c39bccd1
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.
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
This is do aid developers pushing debug services to not need to modify
the underlying SEPolicy
avc: denied { transition } for comm="init" path="/system/bin/awk"
dev="dm-0" ino=1934 scontext=u:r:init:s0 tcontext=u:r:su:s0
tclass=process
avc: denied { rlimitinh } for comm="awk" scontext=u:r:init:s0
tcontext=u:r:su:s0 tclass=process
avc: denied { siginh } for comm="awk" scontext=u:r:init:s0
tcontext=u:r:su:s0 tclass=process
avc: denied { noatsecure } for comm="awk" scontext=u:r:init:s0
tcontext=u:r:su:s0 tclass=process
Test: init can execute a system_file marked with seclabel u:r:su:s0
Change-Id: I85d9528341fe08dbb2fb9a91e34a41f41aa093be
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
