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
Don't audit directory writes to sysfs since they cannot succees
and therefore cannot be a security issue
Bug: 35303861
Test: Make sure denial is no longer shown
Change-Id: I1f31d35aa01e28e3eb7371b1a75fc4090ea40464
On boot, Android runs restorecon on a number of virtual directories,
such as /sys and /sys/kernel/debug, to ensure that the SELinux labels
are correct. To avoid causing excessive boot time delays, the restorecon
code aggressively prunes directories, to avoid recursing down directory
trees which will never have a matching SELinux label.
See:
* https://android-review.googlesource.com/93401
* https://android-review.googlesource.com/109103
The key to this optimization is avoiding unnecessarily broad regular
expressions in file_contexts. If an overly broad regex exists, the tree
pruning code is ineffective, and the restorecon ends up visiting lots of
unnecessary directories.
The directory /sys/kernel/debug/tracing contains approximately 4500
files normally, and on debuggable builds, this number can jump to over
9000 files when the processing from wifi-events.rc occurs. For
comparison, the entire /sys/kernel/debug tree (excluding
/sys/kernel/debug/tracing) only contains approximately 8000 files. The
regular expression "/sys/kernel(/debug)?/tracing/(.*)?" ends up matching
a significant number of files, which impacts boot performance.
Instead of using an overly broad regex, refine the regex so only the
files needed have an entry in file_contexts. This list of files is
essentially a duplicate of the entries in
frameworks/native/cmds/atrace/atrace.rc .
This change reduces the restorecon_recursive call for /sys/kernel/debug
from approximately 260ms to 40ms, a boot time reduction of approximately
220ms.
Bug: 35248779
Test: device boots, no SELinux denials, faster boot.
Change-Id: I70f8af102762ec0180546b05fcf014c097135f3e
Use the default filesystem label from genfs_contexts for the directory
/sys/kernel/debug/tracing and /sys/kernel/tracing, instead of explicitly
attempting to relabel it.
There are three cases we need to consider:
1) Old-style tracing functionality is on debugfs
2) tracing functionality is on tracefs, but mounted under debugfs
3) tracefs is mounted at /sys/kernel/tracing
For #1, the label on /sys/kernel/debug/tracing will be debugfs, and all
processes are allowed debugfs:dir search, so having the label be debugfs
instead of debugfs_tracing will not result in any permission change.
For #2, the label on /sys/kernel/debug/tracing will be debugfs_tracing,
which is the same as it is today. The empty directory
/sys/kernel/tracing wlll retain the sysfs label, avoiding the denial
below.
For #3, /sys/kernel/debug/tracing won't exist, and /sys/kernel/tracing
will have the debugfs_tracing label, where processes are allowed search
access.
Addresses the following denial:
avc: denied { associate } for pid=1 comm="init" name="tracing"
dev="sysfs" ino=95 scontext=u:object_r:debugfs_tracing:s0
tcontext=u:object_r:sysfs:s0 tclass=filesystem permissive=0
Bug: 31856701
Bug: 35197529
Test: no denials on boot
Change-Id: I7233ea92c6987b8edfce9c2f1d77eb25c7df820f
There is only a single systemapi at the moment that is callable, and it is
protected by a signature/preinstalled permission.
(cherry picked from commit I778864afc9d02f8b2bfcf6b92a9f975ee87c4724)
Bug: 35059826,33297721
Test: manually on a marlin
Change-Id: I3789ce8238f5a52ead8f466dfa3045fbcef1958e
