Fixes the following denial during boot:
[ 1.358156] selinux: SELinux: Could not set context for
/dev/block/platform/soc/1d84000.ufshc/by-name/super: Permission denied\x0a
[ 1.358275] audit: type=1400 audit(951562.676:7):
avc: denied { relabelto } for pid=1 comm="init" name="super"
dev="tmpfs" ino=17657 scontext=u:r:init:s0 tcontext=u:object_r:super_block_device:s0
tclass=lnk_file permissive=0
Bug: 124410201
Test: make
Change-Id: Ib6752b8a6ae4211ba8c0a7417295b8144a2fed67
Similar to aosp/961857, but enables the logging of atrace events from
the camera HAL (primarily HIDL interactions, but also a couple of ION
events).
Keeping it confined to userdebug_or_eng. Longer-term planning belongs on
b/78136428.
Not adding fwk_camera_hwservice, as it is a HIDL interface to
cameraserver (which is already covered above).
Plus slight reorganization of existing atrace.te contents, and donaudits
to reduce logspam from denials (including pre-existing ones that were
hitting the rate limiter).
Specific denials addressed (listing HALs, finding camera HAL, notifying it):
05-15 18:07:19.684 618 618 E SELinux : avc: denied { list } for scontext=u:r:atrace:s0 tcontext=u:r:hwservicemanager:s0 tclass=hwservice_manager permissive=1
05-15 18:07:19.701 618 618 E SELinux : avc: denied { find } for interface=android.hardware.camera.provider::ICameraProvider sid=u:r:atrace:s0 pid=10137 scontext=u:r:atrace:s0 tcontext=u:object_r:hal_camera_hwservice:s0 tclass=hwservice_manager permissive=1
05-15 18:07:19.698 10137 10137 I atrace : type=1400 audit(0.0:273): avc: denied { call } for scontext=u:r:atrace:s0 tcontext=u:r:hal_camera_default:s0 tclass=binder permissive=1
Bug: 130543265
Tested: flashed blueline-userdebug, took a trace with perfetto, confirmed HIDL atrace slices present in camera hal trace.
Change-Id: I0f8ce989355603e41d6c05c3de07e7dd615555eb
am: fb897428f6 -s ours
am skip reason: change_id Ifd3fd5fd3a737c7618960343b9f89d3bf7141c94 with SHA1 232295e8db is in history
Change-Id: I69bcc58e51344ea9d46d77055b04e50d7a1857f2
This allows the atrace cmd to notify cameraserver (the host of
media.camera service) that the set of tracing-related system properties
have changed. This allows the cameraserver to notice that it might need
to enable its trace events.
The atrace cmd has the necessary permission when running as shell, but
not when it is running as the "atrace" domain (notably when exec'd by
perfetto's traced_probes).
We're adding cameraserver to the whitelist as it contains important
events for investigating the camera stack.
Example denial:
05-14 22:29:43.501 8648 8648 W atrace : type=1400 audit(0.0:389): avc: denied { call } for scontext=u:r:atrace:s0 tcontext=u:r:cameraserver:s0 tclass=binder permissive=0
Tested: flashed blueline-userdebug, captured a perfetto trace with "camera" atrace category, confirmed that userspace atrace events are included in the trace.
Bug: 130543265
Merged-In: Ifd3fd5fd3a737c7618960343b9f89d3bf7141c94
Change-Id: Ifd3fd5fd3a737c7618960343b9f89d3bf7141c94
(cherry picked from commit 232295e8db)
This allows the atrace cmd to notify cameraserver (the host of
media.camera service) that the set of tracing-related system properties
have changed. This allows the cameraserver to notice that it might need
to enable its trace events.
The atrace cmd has the necessary permission when running as shell, but
not when it is running as the "atrace" domain (notably when exec'd by
perfetto's traced_probes).
We're adding cameraserver to the whitelist as it contains important
events for investigating the camera stack.
Example denial:
05-14 22:29:43.501 8648 8648 W atrace : type=1400 audit(0.0:389): avc: denied { call } for scontext=u:r:atrace:s0 tcontext=u:r:cameraserver:s0 tclass=binder permissive=0
Tested: flashed blueline-userdebug, captured a perfetto trace with "camera" atrace category, confirmed that userspace atrace events are included in the trace.
Bug: 130543265
Change-Id: Ifd3fd5fd3a737c7618960343b9f89d3bf7141c94
installd has been deleting files on the primary (emulated) storage
device for awhile now, but it was lacking the ability to delete files
on secondary (physical) storage devices.
Even though we're always going through an sdcardfs layer, the
kernel checks our access against the label of the real underlying
files.
Instead of tediously listing each possible storage label, using
"sdcard_type" is more descriptive and future-proof as new
filesystems are added.
avc: denied { read open } for path="/mnt/media_rw/1B82-12F6/Android/data/com.android.cts.writeexternalstorageapp" dev="loop9p1" ino=1224 scontext=u:r:installd:s0 tcontext=u:object_r:vfat:s0 tclass=dir permissive=1
avc: denied { write search } for name="cache" dev="loop9p1" ino=1225 scontext=u:r:installd:s0 tcontext=u:object_r:vfat:s0 tclass=dir permissive=1
avc: denied { remove_name } for name="probe" dev="loop9p1" ino=1232 scontext=u:r:installd:s0 tcontext=u:object_r:vfat:s0 tclass=dir permissive=1
avc: denied { unlink } for name="probe" dev="loop9p1" ino=1232 scontext=u:r:installd:s0 tcontext=u:object_r:vfat:s0 tclass=file permissive=1
avc: denied { rmdir } for name="cache" dev="loop9p1" ino=1225 scontext=u:r:installd:s0 tcontext=u:object_r:vfat:s0 tclass=dir permissive=1
Bug: 113277754
Test: atest android.appsecurity.cts.StorageHostTest
Test: atest android.appsecurity.cts.ExternalStorageHostTest
Test: atest --test-mapping frameworks/base/services/core/java/com/android/server/pm/
Change-Id: Id79d8f31627c0bfb490b4280c3b0120d0ef699bf
It doesn't make sense to write neverallow assertions where an attribute
negation exists allowing the operation. When such a negation exists,
domains can "opt-out" of the neverallow assertion by declaring their
use of the attribute. Such trivially bypassable assertions provide
no security nor architectural guarantees.
"netdomain" is such an attribute. This attribute is used by processes to
indicate that they communicate with the network, for example, using
TCP/UDP sockets. Vendor code is freely allowed to use network
communication by declaring their use of the attribute.
Because the attribute is usable to any vendor domain, the "no socket
connections to netd" restriction is pointless and provides a false sense
of security. Any process can opt-out of these restrictions by just
declaring their use of networking functionality. This also results in
ineffective policy bloat, making it difficult to reason about the policy
and make changes.
Delete the ineffective, misleading neverallow assertion.
Test: compiles
Change-Id: Ia72d9660a337ef811e56c9227af29b17d043b99f
Clatd is effectively an internal implementation detail of netd.
It exists as a separate daemon only because this gives us a better
security boundary. Netd is it's only launcher (via fork/exec) and
killer.
Generated via:
{ echo; cat public/clatd.te; echo; } >> private/clatd.te
rm -f public/clatd.te
plus a minor edit to put coredomain after clatd type declaration
and required changes to move netd's clatd use out of public into private.
Test: build and install on non-aosp test device, atest, check for selinux clat denials
Change-Id: I80f110b75828f3657986e64650ef9e0f9877a07c
am: 622992fd49 -s ours
am skip reason: change_id I4339f19af999d43e07995ddb77478a2384bbe209 with SHA1 db3fde05b5 is in history
Change-Id: Ia1b175f2c19e5e3f3e104f85777c081ebc093a54
ART generically locks profile files, and this avoids
special casing the ART code for read-only partitions.
An example on how ART does it:
https://android-review.googlesource.com/c/platform/art/+/958222/3/runtime/jit/jit.cc#731
Bug: 119800099
Test: system server locking a system file, no denial
(cherry picked from commit db3fde05b5)
Change-Id: I5623f5d548dd1226e5788e369333922a27f14021
Merged-In: I4339f19af999d43e07995ddb77478a2384bbe209
These denials are intermittent and unnecessary. Hide them while we
investigate how to properly fix the issue.
Bug: 131096543
Bug: 132093726
Test: Build
Change-Id: I1950c10a93d183c19c510f869419fcfccd5006d2
(cherry picked from commit 654ceeb93f)
am: 7c40e0bb6e -s ours
am skip reason: change_id I1ebd82e6730d62d1966da3c4634ecd78ce703543 with SHA1 487fcb87c0 is in history
Change-Id: I4c57a1b329f9ae1a2e66369658861baf379046b2
am: 24dd16b650 -s ours
am skip reason: change_id Id927ee73469d3e90f5111bd5e31ed760a58c8ebe with SHA1 3e41b297d2 is in history
Change-Id: I14bc89d2151b790278dd6e877312b8edfc05aac4
