sepolicy进阶小记

• 上下文定义

  标准的label取名方式是需要被遵守的，因为很多宏里面就直接用了。。

  hwservice_contexts

  这里标注的是使用hwbinder的服务通信的接口

  标准的label取名方式是以_hwservice结尾

  hwbinder是框架与供应商内容之间的ipc通信模块

  同理，还有个vndbinder，是供应商内容之间的ipc通信模块

  Android 8 之后，原先的binder只适用于框架内通信

  service_contexts

  这里记录的是注册/寻找 binder service 的时候的key
  对应到的是
  ServiceManager.addService(String name, IBinder service)
publishBinderService(String name, IBinder service)
ServiceManager.getService(String name)
  中的name

  标准的label取名方式是以_service结尾

  file_contexts / genfs_contexts

  它们都是用来指定文件的上下文标签
  一般来说，file_contexts用来指定那些inode能够保存上下文信息的文件系统 的 文件上下文
  比如system和vendor分区
  这些上下文被应用的时机是打包生成镜像的时候

  genfs_contexts 则一般用来记录诸如/sys、/proc这样的没有inode的文件系统的 上下文信息
  genfs_contexts 被应用的时机是在开机时

  但是，有一种特殊情况，那就是由于genfs_contexts并不支持正则匹配，因此某些需要正则匹配的 /sys或者/proc内容依然会被放到file_contexts中，这些内容的应用时机也是在开机时

  标准的label取名方式：

  • 可执行文件 以_exec结尾
  • 其它文件，按需 或 按照system/sepolicy中的某些已经type的东西进行定义

  宏定义

  hal_attribute(<hal_name>)

  用来定义三个attribute
  分别是
  hal_<hal_name>
hal_<hal_name>_client
hal_<hal_name>_server

  但是在device tree中直接使用这个宏会导致大规模的neverallow错误，第三方有个workaround
  https://review.lineageos.org/c/LineageOS/android_device_lineage_sepolicy/+/286541
  暂时还不明白原理

  hal_client_domain(, <hal_type>)

  将<domain>定义为<hal_type>_client

  hal_server_domain(, <hal_type>)

  将<domain>定义为<hal_type>_server

  domain_auto_trans(, , )

  当<olddomain>执行label为<type>的文件时，自动转换进程的domain为<newdomain>

  init_daemon_domain()

  这是对上面那个宏的进一步封装
  当init进程（domain为init的进程）执行被label为<domain>_exec的文件时，自动转换进程domain为<domain>

  这是非常常用且重要的一个宏，在为新的可执行文件配置sepolicy的时候必然会用到

  从这里可以看出按照标准进行命名的重要性了吧

  
  

• binder_use / vndbinder_use / hwbinder_use ()

  允许<domain>使用不同种类的binder

  如果一个服务需要使用binder进行通信（包括向对应service manager注册服务），则需要进行此声明

  注意：对于使用hwbinder的服务，如果已经为其定义了hal_server_domain或hal_client_domain，则无需再声明hwbinder_use，原因是上述两个宏会自动将<domain>标注为halserverdomain，从而间接获得hwbinder的使用权限

  binder_call(, )

  允许<clientdomain>向<serverdomain>发起binder IPC通信

  add_hwservice(, )

  允许<domain>向hwservice manager注册<service>接口
  <service>接口的具体信息定义在hwservice_contexts中

  它会自动生成neverallow规则，不再允许别的服务注册这一接口

  hal_attribute_hwservice(, )

  这是对上面那个宏的进一步封装
  它调用add_hwservice(<attribute>_server, <service>)
  并允许<attribute>_client向hwservice manager搜索这个服务
  它会自动生成neverallow规则，不再允许非_server或_client的domain注册或查找服务

  说白了，允许服务端增加服务接口，允许客户端查找获取服务

  很显然，它是需要与hal_attribute、hal_client_domain、hal_server_domain配合使用的

  又是一个规范命名的重要性？

• 流程

  常见的，套路？

  一般可执行文件

  • 创建两个type。一个作为可执行文件执行时的domain，另一个则是给可执行文件的本体使用（<domain>_exec）
  • 在file_contexts中，为可执行文件本体打上<domain>_exec的type
  • 使用init_daemon_domain来实现执行可执行文件时自动切换domain（否则所有的scontext都会为init）
  • 根据其所需权限，为其撰写规则

  HIDL HAL

  • HAL本身是可执行文件，因此在可执行文件的基础上进行
  • 配置hwservice_contexts，声明HAL的接口
  • 额外声明hal_attribute，即hal本体、_server和_client的attribute
  • 使用hal_server_domain将上述“一般可执行文件”中的domain定义为server
  • 将使用HAL的对象定义为hal_client_domain
  • 使用add_hwservice允许server增加服务
  • 使用binder_call允许server和client之间进行通信
  • link: https://blog.xzr.moe/archives/111/