This switches Dumpstate HAL policy to the design which enables us to
conditionally remove unnecessary rules from domains which are clients
of Dumpstate HAL.
Domains which are clients of Dumpstate HAL, such as dumpstate domain,
are granted rules targeting hal_dumpstate only when the Dumpstate 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_dumpstate are not granted to client domains.
Domains which offer a binderized implementation of Dumpstate HAL, such
as hal_dumpstate_default domain, are always granted rules targeting
hal_dumpstate.
Test: adb bugreport
Test: Take bugreport through system UI
Bug: 34170079
Change-Id: I3e827534af03cdfa876921c5fa4af3a53025ba27
In the master external/ipsec-tools/{main.c, racoon.rc},
racoon doesn't call setuid, and doesn't have the setuid capability.
Bug: 35642293
Signed-off-by: Lucas Duffey <lucas.duffey@invapid.org>
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
The preview surface will run in app process and hal_camera will
need to wait on FD generated by preview surface.
Test: the denial is gone, able to take photo in
messenger/hangout/drive application.
Bug: 35589980
Bug: 35485227
Change-Id: I1977174369b104617156065ff25203a17265b707
untrusted_v2_app is basically a refinement of untrusted_app with legacy
capabilities removed and potentially backwards incompatible changes.
This is not currently hooked up to anything.
Bug: 33350220
Test: builds
Change-Id: Ic9fad57476bc2b6022b1eaca8667bf6d844753c2
This removes the compile-time deprecation warning about
hal_impl_domain macro. The warning was introduced in
86e87806f5777a7fc09ea962e694442297e4f8d6. We don't want to spam all
Android platform developers about something internal to the ongoing
SELinux policy restructuring.
Test: Policy compiles without any warnings
Test: Google Play Movies plays back movies (i.e., DRM HAL works)
Bug: 34170079
Change-Id: Icbd4d1283196f7ccc84c2a041c5601113d3c9f21
dumpstate has CAP_SYS_PTRACE solely for the purpose of reading sensitive
/proc/PID files, not for using ptrace attach. Add an assert to ensure
that's the case.
Test: policy compiles.
Change-Id: I975308fae3f8e9a039b9efdc0e9605192b405ce7
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
To determine if it is safe to run fsck on a filesystem, e2fsck
must first determine if the filesystem is mounted. To do that,
e2fsck scans through /proc/mounts and collects all the mounted
block devices. With that information, it runs stat() on each block
device, comparing the major and minor numbers to the filesystem
passed in on the command line. If there is a match, then the filesystem
is currently mounted and running fsck is dangerous.
Allow stat access to all block devices so that fsck can compare
major/minor values.
Addresses the following denials:
avc: denied { getattr } for comm="e2fsck" path="/dev/block/sde5"
dev="tmpfs" ino=15649 scontext=u:r:fsck:s0
tcontext=u:object_r:metadata_block_device:s0 tclass=blk_file
permissive=0
avc: denied { getattr } for comm="e2fsck" path="/dev/block/sda25"
dev="tmpfs" ino=15528 scontext=u:r:fsck:s0
tcontext=u:object_r:modem_block_device:s0 tclass=blk_file permissive=0
avc: denied { getattr } for comm="e2fsck" path="/dev/block/sda31"
dev="tmpfs" ino=15552 scontext=u:r:fsck:s0
tcontext=u:object_r:system_block_device:s0 tclass=blk_file permissive=0
avc: denied { getattr } for comm="e2fsck" path="/dev/block/sdd3"
dev="tmpfs" ino=15600 scontext=u:r:fsck:s0
tcontext=u:object_r:block_device:s0 tclass=blk_file permissive=0
Bug: 35324014
Bug: 33781554
Test: device boots and no SELinux denials.
Change-Id: I5af4a334ec41952887914eec4eee5c60cc441a66
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
Because bootanimation uses the graphics mapper
HIDL service (which is always passthrough), it makes
a call to hwservicemanager to let it know it has
obtained a reference to it.
Bug: 35207188
Test: no more denials from bootanim
Change-Id: I99ea57a0d7777cb84eeaca26426ea38bf72ee933
This switches Camera HAL policy to the design which enables us to
conditionally remove unnecessary rules from domains which are clients
of Camera HAL.
Domains which are clients of Camera HAL, such as cameraserver domain,
are granted rules targeting hal_camera only when the Camera 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_camera are
not granted to client domains.
Domains which offer a binderized implementation of Camera HAL, such
as hal_camera_default domain, are always granted rules targeting
hal_camera.
Test: Take non-HDR photo using Google Camera app
Test: Take HDR photo using Google Camera app
Test: Record video using Google Camera app
Bug: 34170079
Change-Id: I463646cf79fede57f11ccd4ec2cbc37a4fff141e
SELinux labeling of filesystem files ignores symlinks. Unfortunately,
/vendor is a symlink on devices without vendor partition
(e.g., hikey). Thus, policy in directories which are used both for
devices with vendor partition and for devices without vendor partition
must be adjusted to match both /vendor and /system/vendor. It is
assumed that the /vendor symlink, if it exists at all, always points
to /system/vendor.
The alternative solution of adjusting vendor policy file labelling
rules at vendor policy build time, when the actual on-device paths are
known, was considered to make it harder to see how files are labelled
by looking solely at the source tree.
Test: Files under /vendor/bin/hw correctly labelled on sailfish,
angler, and a device which uses the /vendor symlink.
Bug: 35431549
Change-Id: If6ccb2c9cb85b0589db03ab86de8071e15d5366f
Add a label to /proc/config.gz, so we can distinguish this file from
other /proc files in security policy.
For now, only init is allowed read access. All others are denied.
TODO: clarify exactly who needs access. Further access will be granted
in a future commit.
Bug: 35126415
Test: policy compiles and no device boot problems.
Change-Id: I8b480890495ce5b8aa3f8c7eb00e14159f177860
CAP_SYS_PTRACE is no longer used by crash_dump. There's no reason to
exclude it from the neverallow compile time assertion.
Test: policy compiles.
Change-Id: Ib2dced19091406553c16e6ce538cfb68bbc1e5aa
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
This starts the switch for HAL policy to the approach where:
* domains which are clients of Foo HAL are associated with
hal_foo_client attribute,
* domains which offer the Foo HAL service over HwBinder are
associated with hal_foo_server attribute,
* policy needed by the implementation of Foo HAL service is written
against the hal_foo attribute. This policy is granted to domains
which offer the Foo HAL service over HwBinder and, if Foo HAL runs
in the so-called passthrough mode (inside the process of each
client), also granted to all domains which are clients of Foo HAL.
hal_foo is there to avoid duplicating the rules for hal_foo_client
and hal_foo_server to cover the passthrough/in-process Foo HAL and
binderized/out-of-process Foo HAL cases.
A benefit of associating all domains which are clients of Foo HAL with
hal_foo (when Foo HAL is in passthrough mode) is that this removes the
need for device-specific policy to be able to reference these domains
directly (in order to add device-specific allow rules). Instead,
device-specific policy only needs to reference hal_foo and should no
longer need to care which particular domains on the device are clients
of Foo HAL. This can be seen in simplification of the rules for
audioserver domain which is a client of Audio HAL whose policy is
being restructured in this commit.
This commit uses Audio HAL as an example to illustrate the approach.
Once this commit lands, other HALs will also be switched to this
approach.
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: I2597a046753edef06123f0476c2ee6889fc17f20
hal_*_default daemons whose policy is in common/device-agnostic policy
are provided by the vendor image (see vendor/file_contexts). Thus,
their policy should also reside in the vendor image, rather than in
the system image. This means their policy should live in the vendor
subdirectory of this project.
Test: Device boots and appears to work
Bug: 34135607
Bug: 34170079
Change-Id: I6613e43733e03d4a3d4726f849732d903e024016
Motivation:
Provide the ability to phase in new security policies by
applying them to apps with a minimum targetSdkVersion.
Place untrusted apps with targetSdkVersion<=25 into the
untrustd_app_25 domain. Apps with targetSdkVersion>=26 are placed
into the untrusted_app domain. Common rules are included in the
untrusted_app_all attribute. Apps with a more recent targetSdkVersion
are granted fewer permissions.
Test: Marlin builds and boots. Apps targeting targetSdkVersion<=25
run in untrusted_app_25 domain. Apps targeting the current development
build >=26 run in the untrusted_app domain with fewer permissions. No
new denials observed during testing.
Bug: 34115651
Bug: 35323421
Change-Id: Ie6a015566fac07c44ea06c963c40793fcdc9a083
This new input selector allows phasing in new security policies by
giving app developers an opportunity to make any needed compatibility
changes before updating each app's targetSdkVersion.
When all else is equal, matching entries with higher
minTargetSdkVersion= values are preferred over entries with lower
minTargetSdkVersion= values.
Test: Marlin builds and boots. Apps targeting targetSdkVersion<=25
run in untrusted_app_25 domain. Apps targeting the current development
build >=26 run in the untrusted_app domain with fewer permissions. No
new denials observed during testing.
Bug: 34115651
Change-Id: I14bf4f51dbe26cb9bd3f62ad0b281085441d9806
Update shell.te to reflect the fact that hwbinder_user permission is for
lshal, not dumpsys.
Bug: 33382892
Test: pass
Change-Id: I1d298261cea82177436a662afbaa767f00117b16
