Since hal_graphics_composer_default is now no longer
a member of binderservicedomain, these domains would
no longer be able to use filedescriptors from it.
Bug: 36569525
Bug: 35706331
Test: marlin boots, YouTube, Maps, Camera, video
Change-Id: I4c110cf7530983470ae079e4fbc8cf11aa0fab7f
All HALs which are represented by hal_* attributes in SELinux policy
are required to run in binderized mode on Treble devices. This commit
thus makes the SELinux policy for Treble devices no longer associate
domains in hal_x_client with hal_x attribute, which is what was
granting domains hosting clients of hal_x the rules needed to run this
HAL in-process. The result is that core components have now less
access.
This commit has no effect on non-Treble devices.
Test: Device boots -- no new denials
Test: Play movie using Google Play Movies and Netflix
Test: Play YouTube clip in YouTube app and in Chrome
Test: Unlock lock screen using fingerprint
Test: Using Google Camera, take a photo, an HDR+ photo, record a
video with sound, a slow motion video with sound. Photos and
videos display/play back fine (incl. sound).
Test: adb screencap
Test: $ monitor
take screenshot
Test: In all tests, no deials to do with hal_*, except pre-existing
denials to do with hal_gnss.
Bug: 37160141
Bug: 34274385
Bug: 34170079
Change-Id: I1ca91d43592b466114af13898f5909f41e59b521
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
(cherry picked from commit 665128fac3)
The change makes 'vendor_overlay_file' accessible only to few platform
domains like idmap, system_server, zygote and appdomain.
The overlay files contains RROs (runtime resource overlays)
Bug: 36681210
Test: Boot sailfish (treble device) from wiped flashall
Test: Connect to wifi and launch chrome to load few websites.
Test: Launch camera and record + playback video
Change-Id: I3596ca89ad51d0e7d78c75121f22ea71209ee332
Signed-off-by: Sandeep Patil <sspatil@google.com>
The CL splits /vendor labeling from /system. Which was allowing all
processes read, execute access to /vendor.
Following directories will remain world readable
/vendor/etc
/vendor/lib(64)/hw/
Following are currently world readable but their scope
will be minimized to platform processes that require access
/vendor/app
/vendor/framework/
/vendor/overlay
Files labelled with 'same_process_hal_file' are allowed to be
read + executed from by the world. This is for Same process HALs and
their dependencies.
Bug: 36527360
Bug: 36832490
Bug: 36681210
Bug: 36680116
Bug: 36690845
Bug: 36697328
Bug: 36696623
Bug: 36806861
Bug: 36656392
Bug: 36696623
Bug: 36792803
All of the tests were done on sailfish, angler, bullhead, dragon
Test: Boot and connect to wifi
Test: Run chrome and load websites, play video in youtube, load maps w/
current location, take pictures and record video in camera,
playback recorded video.
Test: Connect to BT headset and ensure BT audio playback works.
Test: OTA sideload using recovery
Test: CTS SELinuxHostTest pass
Change-Id: I278435b72f7551a28f3c229f720ca608b77a7029
Signed-off-by: Sandeep Patil <sspatil@google.com>
This futher restricts neverallows for sockets which may be exposed as
filesystem nodes. This is achieved by labelling all such sockets
created by core/non-vendor domains using the new coredomain_socket
attribute, and then adding neverallow rules targeting that attribute.
This has now effect on what domains are permitted to do. This only
changes neverallow rules.
Test: mmm system/sepolicy
Bug: 36577153
(cherry picked from commit cf2ffdf0d8)
Change-Id: Iffeee571a2ff61fb9515fa6849d060649636524e
*mac_permissions.xml files need to be explicitly labeled as they are now split
cross system and vendor and won't have the generic world readable
'system_file' or 'rootfs' label.
Bug: 36003167
Test: no new 'mac_perms_file' denials at boot complete on sailfish
Test: successfully booted into recovery without denials and sideloaded
OTA update.
Test: Launch 'chrome' and succesfully load a website.
Test: Launch Camera and take a picture.
Test: Launch Camera and record a video, succesfully playback recorded
video
Change-Id: I1c882872bb78d1242ba273756ef0dc27487f58fc
Signed-off-by: Sandeep Patil <sspatil@google.com>
file_context files need to be explicitly labeled as they are now split
across system and vendor and won't have the generic world readable
'system_file' label.
Bug: 36002414
Test: no new 'file_context' denials at boot complete on sailfish
Test: successfully booted into recovery without denials and sideloaded
OTA update.
Test: ./cts-tradefed run singleCommand cts --skip-device-info \
--skip-preconditions --skip-connectivity-check --abi \
arm64-v8a --module CtsSecurityHostTestCases -t \
android.security.cts.SELinuxHostTest#testAospFileContexts
Change-Id: I603157e9fa7d1de3679d41e343de397631666273
Signed-off-by: Sandeep Patil <sspatil@google.com>
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
The vrmanager system service connects to vr_window_manager to
provide access to controller data for 2d embedding. This is
intended to be removed when the relevant parts of vr_window_manager
are moved into VrCore (b/36506799).
Bug: 35619424
Test: manual on device
Change-Id: I9c645882bf1a14a85bbc4c2312164381b23aaa54
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
Note: The existing rules allowing socket communication will be removed
once we migrate over to HIDL completely.
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
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
