hal_client_domain no longer allows read dir permission, in order
to load .so from /system/lib, we have to add this permission ourselves.
bug: 37476803
Change-Id: I1711d158c2f4580f50ac244da10c489df003cc18
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
Introduce the add_service() macro which wraps up add/find
permissions for the source domain with a neverallow preventing
others from adding it. Only a particular domain should
add a particular service.
Use the add_service() macro to automatically add a neverallow
that prevents other domains from adding the service.
mediadrmserver was adding services labeled mediaserver_service.
Drop the add permission as it should just need the find
permission.
Additionally, the macro adds the { add find } permission which
causes some existing neverallow's to assert. Adjust those
neverallow's so "self" can always find.
Test: compile and run on hikey and emulator. No new denials were
found, and all services, where applicable, seem to be running OK.
Change-Id: Ibbd2a5304edd5f8b877bc86852b0694732be993c
Signed-off-by: William Roberts <william.c.roberts@intel.com>
HAL clients should not be annotated with hal_x and haldomain. This may
grant them too much access. Instead, the policy needed for using
in-process HALs should be directly embedded into the client's domain
rules.
This reverts the moving of rules out of mediadrmserver in commit
c86f42b9a7.
Test: YouTube videos play back, no mediadrmserver denials
Bug: 34715716
Bug: 32815560
Change-Id: Ib57ef880bcc306c6e01f2c24c0f3a4298598eb9a
reflect the change from "mediaanalytics" to "mediametrics"
Also incorporates a broader access to the service -- e.g. anyone.
This reflects that a number of metrics submissions come from application
space and not only from our controlled, trusted media related processes.
The metrics service (in another commit) checks on the source of any
incoming metrics data and limits what is allowed from unprivileged
clients.
Bug: 34615027
Test: clean build, service running and accessible
Change-Id: I657c343ea1faed536c3ee1940f1e7a178e813a42
This restricts access to ro.serialno and ro.boot.serialno, the two
system properties which contain the device's serial number, to a
select few SELinux domains which need the access. In particular, this
removes access to these properties from Android apps. Apps can access
the serial number via the public android.os.Build API. System
properties are not public API for apps.
The reason for the restriction is that serial number is a globally
unique identifier which cannot be reset by the user. Thus, it can be
used as a super-cookie by apps. Apps need to wean themselves off of
identifiers not resettable by the user.
Test: Set up fresh GMS device, install some apps via Play, update some apps, use Chrome
Test: Access the device via ADB (ADBD exposes serial number)
Test: Enable MTP over USB, use mtp-detect to confirm that serial number is reported in MTP DeviceInfo
Bug: 31402365
Bug: 33700679
Change-Id: I4713133b8d78dbc63d8272503e80cd2ffd63a2a7
media framework analytics are gathered in a separate service.
define a context for this new service, allow various
media-related services and libraries to access this new service.
Bug: 30267133
Test: ran media CTS, watched for selinux denials.
Change-Id: I5aa5aaa5aa9e82465b8024f87ed32d6ba4db35ca
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
