platform_system_sepolicy/public/hal_omx.te
Steven Moreland 8fc7981885 Find hal_foo_hwservice -> you are hal_foo_client.
Before, it was possible to access a hwservice without declaring
that you were a client.

This introduces the following macro:
hal_attribute_hwservice_client(hal_foo, hal_foo_hwservice)

which makes sure the above implication holds using a neverallow rule.

Bug: 80319537
Test: boot + sanity
Change-Id: Iededae68f14f0f3bd412c1205aa3b650a54d55c6
2018-05-30 16:46:57 -07:00

56 lines
2.2 KiB
Text

# applies all permissions to hal_omx NOT hal_omx_server
# since OMX must always be in its own process.
add_hwservice(hal_omx_server, hal_codec2_hwservice)
add_hwservice(hal_omx_server, hal_omx_hwservice)
# can route /dev/binder traffic to /dev/vndbinder
vndbinder_use(hal_omx_server)
binder_call(hal_omx_server, binderservicedomain)
binder_call(hal_omx_server, { appdomain -isolated_app })
# Allow hal_omx_server access to composer sync fences
allow hal_omx_server hal_graphics_composer:fd use;
allow hal_omx_server gpu_device:chr_file rw_file_perms;
allow hal_omx_server video_device:chr_file rw_file_perms;
allow hal_omx_server video_device:dir search;
allow hal_omx_server ion_device:chr_file rw_file_perms;
allow hal_omx_server hal_camera:fd use;
crash_dump_fallback(hal_omx_server)
# Recieve gralloc buffer FDs from bufferhubd. Note that hal_omx_server never
# directly connects to bufferhubd via PDX. Instead, a VR app acts as a bridge
# between those two: it talks to hal_omx_server via Binder and talks to bufferhubd
# via PDX. Thus, there is no need to use pdx_client macro.
allow hal_omx_server bufferhubd:fd use;
hal_attribute_hwservice_client(hal_omx, hal_omx_hwservice)
hal_attribute_hwservice_client(hal_omx, hal_codec2_hwservice)
allow hal_omx_client hidl_token_hwservice:hwservice_manager find;
binder_call(hal_omx_client, hal_omx_server)
binder_call(hal_omx_server, hal_omx_client)
###
### neverallow rules
###
# hal_omx_server should never execute any executable without a
# domain transition
neverallow hal_omx_server { file_type fs_type }:file execute_no_trans;
# The goal of the mediaserver split is to place media processing code into
# restrictive sandboxes with limited responsibilities and thus limited
# permissions. Example: Audioserver is only responsible for controlling audio
# hardware and processing audio content. Cameraserver does the same for camera
# hardware/content. Etc.
#
# Media processing code is inherently risky and thus should have limited
# permissions and be isolated from the rest of the system and network.
# Lengthier explanation here:
# https://android-developers.googleblog.com/2016/05/hardening-media-stack.html
neverallow hal_omx_server domain:{ tcp_socket udp_socket rawip_socket } *;