Android 8.1 write HAL from scratch – (5) add execution permission

Note: This article is based on Android 8.1 for analysis
Qidi　2020.07.20　(Markdown & Haroopad)

[preface]

SELinux is used to manage permissions on Android. Although in the last article Android 8.1 writing HAL from scratch – (4) compilation and packaging In, demoComponent HAL has been successfully compiled and packaged into the system image, but so far it has not been given access to Binder. Therefore, we will at least see that when demoService is registered as Binder service, the following prompt will be printed in the log:

[   10.368517] type=1400 audit(1483292256.112:14): avc: denied { add } ...

•  

This article is to explain how to improve the SELinux permissions required by demoComponent HAL.

1, Write policy file

According to the habits of different companies, the files used to configure product permissions are generally placed in / device / < CompanyName > / sepolicy / or / device / < CompanyName > / common / sepolicy / directory (it does not rule out the possibility of other paths, but it must be a certain sepolicy / subdirectory under the device / directory) [1]. In this directory, create corresponding subdirectories for different parts, and create *. In this subdirectory # documents and*_ contexts file to add the necessary permissions.

Take the platform I am using as an example, create a new directory / device/harman/sepolicy/demoComponent /, and create a new file in this directory as shown in the following figure:

Describe the contents and functions of the following documents:

• file_contexts:
  First write a file_contexts file. This file name is fixed by the SELinux framework. We're in a file_ The executables of demoService are defined as security objects in contexts.

  # define demoService executable binary as a security object
  /vendor/bin/hw/vendor.harman.demoComponent.demoService@1.0-service   u:object_r:demoService_exec:s0
  

• hwservice_contexts:
  Then, because demoComponent HAL relies on hwbinder for communication, we also need to write hwservice_contexts. This file name is also fixed by the SELinux framework. In this file, we define the new interface as a security object, function and file_contexts are similar. (if you use vndbinder, you should write vndservice_contexts)
  Since Android 8.0, SELinux has also been divided into system part and vendor part. Because different components use different binder nodes, the vendor part changes from the original unique service_ The hwservice is stripped out of the context #_ Contexts and vndservice_contexts # two files. When using / dev/hwbinder ， create the former manually and add definitions to the file; when using / dev/vndbinder ， create the latter and add definitions to the file as well.

  # define HAL interface as a security object
  vendor.harman.hardware.demoComponent.demoService::IDemoServiceDef  u:object_r:vendor_demoService_hwservice:s0
  

• hwservicemanager.te:
  Since we are using hwbinder node, we should also write hwservicemanager te. The file name is also fixed. Declare in this file that demoService needs to use hwbinder. (if you use vndbinder, you should write vndservicemanager.te)

  # grant demoService permission of using hwbinder
  hwbinder_use(demoService)
  

• hwservice.te:
  Similarly, write hwservice te. The file name is still fixed. In this file, the exclusive hwservice type is defined for demoService, which will be used when adding the "register service" permission. (if you use vndbinder, you should write vndservice.te)

  # define demoService as hwservice_manager, so it can be added as a hwservice
  type vendor_demoService_hwservice, hwservice_manager_type;
  

• demoService.te:
  Then write demoService File. This file is usually named after the object that needs to add permissions. In this file, we define an exclusive security domain for demoService, give the required file attributes to the executable file of demoService, and add necessary permissions related to Binder operation for demoService domain, such as "register as service", "allow hwbinder call", etc.
  Different HAL processes or local services have different files to operate, and their implementation functions are also different, so the contents of this file are also very different. According to the minimum permission rule, you can add permissions according to your actual needs. [2]

  # define a security domain for demo service
  type demoService, domain;
  
  # specify demo service attributes
  type demoService_exec, exec_type, file_type, vendor_file_type;
  
  # initialize demo service domain
  init_daemon_domain(demoService)
  
  add_hwservice(demoService, vendor_demoService_hwservice)
  
  binder_call(demoService, vndservicemanager)
  binder_call(demoService, hwservicemanager)
  binder_call(demoService, system_app)
  
  allow demoService vndbinder_device:chr_file rw_file_perms;
  allow demoService hwservicemanager_prop:file r_file_perms;
  

• system_app.te:
  Finally, add call permission to the user process. Because in the next article Android 8.1 writing HAL from scratch – (6) testing HAL In, I will take APP's call to demoService as an example to illustrate the calling process, so a new demo system is created here_ APP. te. For system_ Add APP through hwservice_manager finds the service and the permission to call demoService through binder.

  # APP access priviledges for demoService
  binder_call(system_app, demoService)
  allow system_app vendor_demoService_hwservice:hwservice_manager find;
  

2, Apply policy file

In order for the new security rules to take effect, you need to add the newly created directory to the Makefile so that you can scan it when compiling the image. We usually add this change to / device / < CompanyName > / < platformname > / < ProductName > / boardconfig mk.
The file I changed here is / device / Harman / Broxton / XXXX / boardconfig MK, amend as follows:

diff --git a/XXXX/BoardConfig.mk b/XXXX/BoardConfig.mk
index 4979507a7..8e700f22d 100755
--- a/XXXX/BoardConfig.mk
+++ b/XXXX/BoardConfig.mk
@@ -72,6 +72,12 @@ BOARD_SEPOLICY_DIRS += device/harman/sepolicy/vold
 INTEL_AUDIO_HAL=imc
 BOARD_SEPOLICY_DIRS += device/harman/sepolicy/audio
+
+########################################################
+# DemoService
+########################################################
+BOARD_SEPOLICY_DIRS += device/harman/sepolicy/demoComponent
+

[Conclusion]

After full compilation, burn the image to the device. After the device is started, execute the command | ps -A | grep -i demo, and finally you can see that our demoComponent HAL process has been successfully started with the system.

If you execute the command "logcat | grep -i demo" when the system is just started, you can also see the log printing of demoComponent HAL registered as Binder service:

The next article will take APP calling demoService as an example to illustrate the calling method.

[References]

[1] Implementing SELinux, https://source.android.com/security/selinux/implement
[2] Policy compatibility, https://source.android.com/security/selinux/compatibility