| 12345678910111213141516171819202122232425262728293031323334353637383940414243444546 |
- # applies all permissions to hal_omx NOT hal_omx_server
- # since OMX must always be in its own process.
- 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 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(hal_omx, hal_omx_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 } *;
|
