This is needed for timerslack functionality which should be present in
most kernels going forward
Test: system_server can write to cameraserver files
Change-Id: I85797128b1467d92eb354364de8eb60f8e45c931
Bug: 62706738
Bug: 34133340
Test: Check that uid_time_in_state can't be read from
the shell without root permissions and that
"dumpsys batterystats --checkin| grep ctf" shows frequency
data (system_server was able to read uid_time_in_state)
Change-Id: Ic6a54da4ebcc9e10b0e3af8f14a45d7408e8686e
(cherry picked from commit 4dc88795d0)
In libprocessgroup, we want to only send signals once to processes,
particularly for SIGTERM. We must send the signal both to all
processes within a POSIX process group and a cgroup. To ensure that
we do not duplicate the signals being sent, we check the processes in
the cgroup to see if they're in the POSIX process groups that we're
killing. If they are, we skip sending a second signal. This requires
getpgid permissions, hence this SELinux change.
avc: denied { getpgid } for pid=797 comm="ActivityManager" scontext=u:r:system_server:s0 tcontext=u:r:untrusted_app_25:s0:c512,c768 tclass=process permissive=1
avc: denied { getpgid } for pid=797 comm="ActivityManager" scontext=u:r:system_server:s0 tcontext=u:r:untrusted_app_25:s0:c512,c768 tclass=process permissive=1
avc: denied { getpgid } for pid=797 comm="ActivityManager" scontext=u:r:system_server:s0 tcontext=u:r:system_app:s0 tclass=process permissive=1
avc: denied { getpgid } for pid=797 comm="ActivityManager" scontext=u:r:system_server:s0 tcontext=u:r:system_app:s0 tclass=process permissive=1
avc: denied { getpgid } for pid=1 comm="init" scontext=u:r:init:s0 tcontext=u:r:zygote:s0 tclass=process permissive=1
avc: denied { getpgid } for pid=1 comm="init" scontext=u:r:init:s0 tcontext=u:r:zygote:s0 tclass=process permissive=1
avc: denied { getpgid } for pid=1 comm="init" scontext=u:r:init:s0 tcontext=u:r:system_server:s0 tclass=process permissive=1
avc: denied { getpgid } for pid=1 comm="init" scontext=u:r:init:s0 tcontext=u:r:system_server:s0 tclass=process permissive=1
Bug: 37853905
Bug: 62418791
Test: Boot, kill zygote, reboot
Change-Id: Ib6c265dbaac8833c47145ae28fb6594ca8545570
tombstoned allows dumpstate to install "intercepts" to java trace
requests for a given process. When an "intercept" is installed, all
trace output is redirected to a pipe provided by dumpstate instead
of the default location (usually in /data/anr or /data/tombstone).
Note that these processes are already granted "write" and "getattr"
on dumpstate:fifo_file in order to communicate with dumpstate; this
change adds "append" to the existing set of permissions.
Bug: 32064548
Test: manual
Change-Id: Iccbd78c59071252fef318589f3e55ece51a3c64c
Applications connect to tombstoned via a unix domain socket and request
an open FD to which they can write their traces. This socket has a new
label (tombstoned_java_trace_socket) and appdomain and system_server are
given permissions to connect and write to it.
Apps no longer need permissions to open files under /data/anr/ and
these permissions will be withdrawn in a future change.
Bug: 32064548
Test: Manual
Merged-In: I70a3e6e230268d12b454e849fa88418082269c4f
Change-Id: Ib4b73fc130f4993c44d96c8d68f61b6d9bb2c7d5
Bluetooth needs the capability to set audio-related threads to be RT
scheduled. Grant it sys_nice.
system_server needs to set priority for the Bluetooth HAL. Allow it.
Bug 37518404
Test: Play Bluetooth audio, confirm RT scheduling with systrace
Change-Id: Iaf7b85a11a51883744d72a50addfd320b6fbbc2f
With build/core eaa9d88cf, system_server should not be loading code
from /data. Add an auditallow rule to report violations.
Bug: 37214733
Test: Boot marlin, no SELinux audit lines for system_server.
Change-Id: I2e25eb144503274025bd4fc9bb519555851f6521
This change associates all domains which are clients of Allocator HAL
with hal_allocator_client and the, required for all HAL client
domains, halclientdomain.
This enables this commit to remove the now unnecessary hwallocator_use
macro because its binder_call(..., hal_allocator_server) is covered by
binder_call(hal_allocator_client, hal_allocator_server) added in this
commit.
Unfortunately apps, except isolated app, are clients of Allocator HAL
as well. This makes it hard to use the hal_client_domain(...,
hal_allocator) macro because it translates into "typeattribute" which
currently does not support being provided with a set of types, such as
{ appdomain -isolated_app }. As a workaround, hopefully until
typeattribute is improved, this commit expresses the necessary
association operation in CIL. private/technical_debt.cil introduced by
this commit is appended into the platform policy CIL file, thus
ensuring that the hack has effect on the final monolithic policy.
P. S. This change also removes Allocator HAL access from isolated_app.
Isolated app shouldn't have access to this HAL anyway.
Test: Google Play Music plays back radios
Test: Google Camera records video with sound and that video is then
successfully played back with sound
Test: YouTube app plays back clips with sound
Test: YouTube in Chrome plays back clips with sound
Bug: 34170079
Change-Id: Id00bba6fde83e7cf04fb58bc1c353c2f66333f92
On PRODUCT_FULL_TREBLE devices, non-vendor domains (except vendor
apps) are not permitted to use Binder. This commit thus:
* groups non-vendor domains using the new "coredomain" attribute,
* adds neverallow rules restricting Binder use to coredomain and
appdomain only, and
* temporarily exempts the domains which are currently violating this
rule from this restriction. These domains are grouped using the new
"binder_in_vendor_violators" attribute. The attribute is needed
because the types corresponding to violators are not exposed to the
public policy where the neverallow rules are.
Test: mmm system/sepolicy
Test: Device boots, no new denials
Test: In Chrome, navigate to ip6.me, play a YouTube video
Test: YouTube: play a video
Test: Netflix: play a movie
Test: Google Camera: take a photo, take an HDR+ photo, record video with
sound, record slow motion video with sound. Confirm videos play
back fine and with sound.
Bug: 35870313
Change-Id: I0cd1a80b60bcbde358ce0f7a47b90f4435a45c95
ASAN builds may require additional permissions to launch processes
with ASAN wrappers. In this case, system_server needs permission to
execute /system/bin/sh.
Create with_asan() macro which can be used exclusively on debug
builds. Note this means that ASAN builds with these additional
permission will not pass the security portion of CTS - like any
other debug build.
Addresses:
avc: denied { execute } for name="sh" dev="dm-0" ino=571
scontext=u:r:system_server:s0 tcontext=u:object_r:shell_exec:s0
tclass=file
Test: lunch aosp_marlin-userdebug;
cd system/sepolicy; mm SANITIZE_TARGET=address;
Verify permissions granted using with_asan() are granted.
Test: lunch aosp_marlin-userdebug;
cd system/sepolicy; mm;
Verify permissions granted using with_asan() are not granted.
Test: lunch aosp_marlin-user;
cd system/sepolicy; mm SANITIZE_TARGET=address;
Verify permissions granted using with_asan() are not granted.
Bug: 36138508
Change-Id: I6e39ada4bacd71687a593023f16b45bc16cd7ef8
Now that the android wifi framework has fully switched over to HIDL,
remove the sepolicy permissions for accessing wpa_supplicant using
socket control interface.
While there, also removed the redundant |hwbinder_use|.
Bug: 35707797
Test: Device boots up and able to connect to wifi networks.
Test: Wifi integration tests passed.
Change-Id: I55e24b852558d1a905b189116879179d62bdc76c
This switches Boot Control HAL policy to the design which enables us
to conditionally remove unnecessary rules from domains which are
clients of Boot Control HAL.
Domains which are clients of Boot Control HAL, such as update_server,
are granted rules targeting hal_bootctl only when the Boot Control HAL
runs in passthrough mode (i.e., inside the client's process). When the
HAL runs in binderized mode (i.e., in another process/domain, with
clients talking to the HAL over HwBinder IPC), rules targeting
hal_bootctl are not granted to client domains.
Domains which offer a binderized implementation of Boot Control HAL,
such as hal_bootctl_default domain, are always granted rules targeting
hal_bootctl.
P. S. This commit removes direct access to Boot Control HAL from
system_server because system_server is not a client of this HAL. This
commit also removes bootctrl_block_device type which is no longer
used. Finally, boot_control_hal attribute is removed because it is now
covered by the hal_bootctl attribute.
Test: Device boots up, no new denials
Test: Reboot into recovery, sideload OTA update succeeds
Test: Apply OTA update via update_engine:
1. make dist
2. Ensure device has network connectivity
3. ota_call.py -s <serial here> out/dist/sailfish-ota-*.zip
Bug: 34170079
Change-Id: I9c410c092069e431a3852b66c04c4d2a9f1a25cf
This switches most remaining HALs to the _client/_server approach.
To unblock efforts blocked on majority of HALs having to use this
model, this change does not remove unnecessary rules from clients of
these HALs. That work will be performed in follow-up commits. This
commit only adds allow rules and thus does not break existing
functionality.
The HALs not yet on the _client/_server model after this commit are:
* Allocator HAL, because it's non-trivial to declare all apps except
isolated apps as clients of this HAL, which they are.
* Boot HAL, because it's still on the non-attributized model and I'm
waiting for update_engine folks to answer a couple of questions
which will let me refactor the policy of this HAL.
Test: mmm system/sepolicy
Test: Device boots, no new denials
Test: Device boots in recovery mode, no new denials
Bug: 34170079
Change-Id: I03e6bcec2fa02f14bdf17d11f7367b62c68a14b9
Test: no log spam for graphics allocator
Test: dmesg | audit2allow does not show denial for
hal_graphics_allocator_default
Test: system is responsive after boot (because
android.hardware.graphics.allocator@2.0::IAllocator getService()
will not be blocked)
Bug: 36220026
Change-Id: I3e103f88988fe4a94888e92ee8c5b1f27845ad9e
This switches Sensors HAL policy to the design which enables us to
conditionally remove unnecessary rules from domains which are clients
of Sensors HAL.
Domains which are clients of Sensors HAL, such as system_server, are
granted rules targeting hal_sensors only when the Sensors HAL runs in
passthrough mode (i.e., inside the client's process). When the HAL
runs in binderized mode (i.e., in another process/domain, with clients
talking to the HAL over HwBinder IPC), rules targeting hal_sensors are
not granted to client domains.
Domains which offer a binderized implementation of Sensors HAL, such
as hal_sensors_default domain, are always granted rules targeting
hal_sensors.
P. S. This commit also removes
allow system_server sensors_device:chr_file rw_file_perms
because this is device-specific and thus not needed in device-agnostic
policy. The device-specific policy of the affected devices already has
this rule.
Test: Device boots, no new denials
Test: adb shell dumpsys sensorservice
lists tons of sensors
Test: Proprietary sensors test app indicates that there are sensors
and that the app can register to listen for updates for sensors
and that such updates arrive to the app.
Bug: 34170079
Change-Id: I61bf779070eabcb64ae73724d62b6e837319a668
We simplified the way we track whether or not a dex file is used by
other apps. DexManager in the framework keeps track of the data and we
no longer need file markers on disk.
Test: device boots, foreign dex markers are not created anymore
Bug: 32871170
Change-Id: I464ed6b09439cf0342020ee07596f9aa8ae53b62
Note: The existing rules allowing socket communication will be removed
once we migrate over to HIDL completely.
(cherry-pick of 2a9595ede2)
Bug: 34603782
Test: Able to connect to wifi networks.
Test: Will be sending for full wifi integration tests
(go/wifi-test-request)
Change-Id: I9ee238fd0017ec330f6eb67ef9049211f7bd4615
The new wifi HAL manages the wlan driver and hence needs to be able to
load/unload the driver. The "wlan.driver.status" is used to indicate the
state of the driver to the rest of the system. There are .rc scripts for
example which wait for the state of this property.
Denials:
03-01 13:31:43.394 476 476 W android.hardwar: type=1400
audit(0.0:7243): avc: denied { read } for name="u:object_r:wifi_prop:s0"
dev="tmpfs" ino=10578 scontext=u:r:hal_wifi_default:s0
tcontext=u:object_r:wifi_prop:s0 tclass=file permissive=0
03-01 13:31:43.399 476 476 E libc : Access denied finding
property "wlan.driver.status"
Bug: 35765841
Test: Denials no longer seen
Change-Id: I502494af7140864934038ef51cb0326ba3902c63
Previously, we'd restricted WifiService's use of
the kernel's tracing feature to just userdebug_or_eng
builds.
This restriction was in place because the feature
had not yet been reviewed from a privacy perspective.
Now that the feature has passed privacy review, enable
the feature on all builds.
Note that other safeguards remain in place (on all
builds):
- The set of events to be monitored is configured by
init, rather than WifiService (part of system_server).
This privilege separation prevents a compromised
system_server from tracing additional information.
- The trace events are kept only in RAM, until/unless
WifiService receives a dump request. (This would happen,
for example, in the case of adb dumpsys, or generating
a bugreport.)
Bug: 35679234
Test: manual (see below)
Manual test details:
- flash device
- connect device to a wifi network
$ adb shell dumpsys wifi | grep rdev_connect
[should see at least one matching line]
Change-Id: I85070054857d75177d0bcdeb9b2c95bfd7e3b6bc
This switches Wi-Fi HAL policy to the design which enables us to
conditionally remove unnecessary rules from domains which are clients
of Wi-Fi HAL.
Domains which are clients of Wi-Fi HAL, such as system_server domain,
are granted rules targeting hal_wifi only when the Wi-Fi HAL runs in
passthrough mode (i.e., inside the client's process). When the HAL
runs in binderized mode (i.e., in another process/domain, with clients
talking to the HAL over HwBinder IPC), rules targeting hal_wifi are
not granted to client domains.
Domains which offer a binderized implementation of Wi-Fi HAL, such as
hal_wifi_default domain, are always granted rules targeting hal_wifi.
Test: Setup Wizard (incl. adding a Google Account) completes fine with
Wi-Fi connectivity only
Test: Toggle Wi-Fi off, on, off, on
Test: Use System UI to see list of WLANs and connect to one which does
not require a password, and to one which requries a PSK
Test: ip6.me loads fine in Chrome over Wi-Fi
Bug: 34170079
Change-Id: I7a216a06727c88b7f2c23d529f67307e83bed17f
This switches Fingerprint HAL policy to the design which enables us to
conditionally remove unnecessary rules from domains which are clients
of Bluetooth HAL.
Domains which are clients of Fingerprint HAL, such as system_server
domain, are granted rules targeting hal_fingerprint only when the
Fingerprint HAL runs in passthrough mode (i.e., inside the client's
process). When the HAL runs in binderized mode (i.e., in another
process/domain, with clients talking to the HAL over HwBinder IPC),
rules targeting hal_fingerprint are not granted to client domains.
Domains which offer a binderized implementation of Fingerprint HAL,
such as hal_fingerprint_default domain, are always granted rules
targeting hal_fingerprint.
NOTE: This commit also removes unnecessary allow rules from
Fingerprint HAL, such access to servicemanager (not hwservicemanager)
and access to keystore daemon over Binder IPC. Fingerprint HAL does
not use this functionality anyway and shouldn't use it either.
Test: Enable fingerprint + PIN secure lock screen, confirm it unlocks
with fingerprint or PIN
Test: Disable PIN (and thus fingerprint) secure lock screen
Test: make FingerprintDialog, install, make a fake purchase
Test: Add fingerprint_hidl_hal_test to device.mk, build & add to device,
adb shell stop,
adb shell /data/nativetest64/fingerprint_hidl_hal_test/fingerprint_hidl_hal_test -- all tests pass
Bug: 34170079
Change-Id: I6951c0f0640194c743ff7049357c77f5f21b71a1
This switches DRM HAL policy to the design which enables us to
conditionally remove unnecessary rules from domains which are clients
of DRM HAL.
Domains which are clients of DRM HAL, such as mediadrmserver domain,
are granted rules targeting hal_drm only when the DRM HAL runs in
passthrough mode (i.e., inside the client's process). When the HAL
runs in binderized mode (i.e., in another process/domain, with
clients talking to the HAL over HwBinder IPC), rules targeting hal_drm
are not granted to client domains.
Domains which offer a binderized implementation of DRM HAL, such as
hal_drm_default domain, are always granted rules targeting hal_drm.
Test: Play movie using Google Play Movies
Test: Play movie using Netflix
Bug: 34170079
Change-Id: I3ab0e84818ccd61e54b90f7ade3509b7dbf86fb9
This switches Bluetooth HAL policy to the design which enables us to
conditionally remove unnecessary rules from domains which are clients
of Bluetooth HAL.
Domains which are clients of Bluetooth HAL, such as bluetooth domain,
are granted rules targeting hal_bluetooth only when the Bluetooth HAL
runs in passthrough mode (i.e., inside the client's process). When the
HAL runs in binderized mode (i.e., in another process/domain, with
clients talking to the HAL over HwBinder IPC), rules targeting
hal_bluetooth are not granted to client domains.
Domains which offer a binderized implementation of Bluetooth HAL, such
as hal_bluetooth_default domain, are always granted rules targeting
hal_bluetooth.
Test: Toggle Bluetooth off and on
Test: Pair with another Android, and transfer a file to that Android
over Bluetooth
Test: Pair with a Bluetooth speaker, play music through that
speaker over Bluetooth
Test: Add bluetooth_hidl_hal_test to device.mk, build & add to device,
adb shell stop,
adb shell /data/nativetest64/bluetooth_hidl_hal_test/bluetooth_hidl_hal_test
Bug: 34170079
Change-Id: I05c3ccf1e98cbbc1450a81bb1000c4fb75eb8a83
Much like audio, the camera HAL may need to have key threads running
in SCHED_FIFO or similar priority. Allow system_server to raise
thread priority for camera HALs to make this possible.
Test: Video recording works, with EIS. No logspam about EIS failure.
Bug: 35389145
Change-Id: I1d92f9f10dc3aff22ce56b8b9cc57db043631919
Move net.dns* from net_radio_prop to the newly created label
net_dns_prop. This allows finer grain control over this specific
property.
Prior to this change, this property was readable to all SELinux domains,
and writable by the following SELinux domains:
* system_server
* system_app (apps which run as UID=system)
* netmgrd
* radio
This change:
1) Removes read access to this property to everyone EXCEPT untrusted_app
and system_server.
2) Limit write access to system_server.
In particular, this change removes read access to priv_apps. Any
priv_app which ships with the system should not be reading this
property.
Bug: 34115651
Test: Device boots, wifi turns on, no problems browsing the internet
Change-Id: I8a32e98c4f573d634485c4feac91baa35d021d38
This leaves only the existence of system_server domain as public API.
All other rules are implementation details of this domain's policy
and are thus now private.
Test: No change to policy according to sesearch, except for
disappearance of all allow rules to do with
system_server_current except those created by other domains'
allow rules referencing system_server domain from public and
vendor policies.
Bug: 31364497
Change-Id: Ifd76fa83c046b9327883eb6f0bbcd2113f2dd1a4
This CLs adds SElinux policies necessary to compile secondary dex files.
When an app loads secondary dex files via the base class loader the
files will get reported to PM. During maintance mode PM will compile the
secondary dex files which were used via the standard installd model
(fork, exec, change uid and lower capabilities).
What is needed:
dexoptanalyzer - needs to read the dex file and the boot image in order
to decide if we need to actually comppile.
dex2oat - needs to be able to create *.oat files next to the secondary
dex files.
Test: devices boots
compilation of secondary dex files works without selinux denials
cmd package compile --secondary-dex -f -m speed
com.google.android.gms
Bug: 32871170
Change-Id: I038955b5bc9a72d49f6c24c1cb76276e0f53dc45
Replace the global debuggerd with a per-process debugging helper that
gets exec'ed by the process that crashed.
Bug: http://b/30705528
Test: crasher/crasher64, `debuggerd <pid>`, `kill -ABRT <pid>`
Change-Id: Iad1b7478f7a4e2690720db4b066417d8b66834ed
In order to support platform changes without simultaneous updates from
non-platform components, the platform and non-platform policies must be
split. In order to provide a guarantee that policy written for
non-platform objects continues to provide the same access, all types
exposed to non-platform policy are versioned by converting them and the
policy using them into attributes.
This change performs that split, the subsequent versioning and also
generates a mapping file to glue the different policy components
together.
Test: Device boots and runs.
Bug: 31369363
Change-Id: Ibfd3eb077bd9b8e2ff3b2e6a0ca87e44d78b1317
Divide policy into public and private components. This is the first
step in splitting the policy creation for platform and non-platform
policies. The policy in the public directory will be exported for use
in non-platform policy creation. Backwards compatibility with it will
be achieved by converting the exported policy into attribute-based
policy when included as part of the non-platform policy and a mapping
file will be maintained to be included with the platform policy that
maps exported attributes of previous versions to the current platform
version.
Eventually we would like to create a clear interface between the
platform and non-platform device components so that the exported policy,
and the need for attributes is minimal. For now, almost all types and
avrules are left in public.
Test: Tested by building policy and running on device.
Change-Id: Idef796c9ec169259787c3f9d8f423edf4ce27f8c
