我的自定义 selinux 策略似乎被 Android 系统忽略

我在基于 AOSP 的 Android 7.1.2（更准确地说是基于索尼开放设备树）上正确运行自定义 selinux 策略时遇到了一些麻烦。

我的问题是审核日志不断告诉我缺少我实际添加的文件访问规则。我还将audit2allow 创建的规则复制到我的策略文件中，但即使这些规则也无法正常工作。

那么，让我们深入了解细节：

我创建了一个名为的自定义域供应商应用程序。该域根据应用程序的签名分配给应用程序。我已经添加了一个条目mac_permissions.xml分配seinfo字段vendor. In seaapp_contexts我分配供应商应用程序像这样的域名：

user=_app seinfo=vendor domain=vendor_app type=app_data_file levelFrom=user

我的应用程序在供应商应用程序上下文中正确启动：

# ps -Z | grep permissiontest
u:r:vendor_app:s0:c512,c768    u0_a109   4110  508   1620732 79584 SyS_epoll_ 0000000000 S com.vendor.android.permissiontest

所以，现在来说说根本不起作用的部分。一个应用程序运行在供应商应用程序上下文应获得对文件的读/写访问权限/坚持/供应商。为了创建必要的规则，我添加了一个名为的文件供应商.te to the sepolicy设备目录中的文件夹包含以下内容：

type vendor_app, domain;
type vendor_file, file_type, data_file_type;
# permissive vendor_app;

app_domain(vendor_app)
net_domain(vendor_app)
bluetooth_domain(vendor_app)

allow vendor_app persist_file:dir r_dir_perms;
allow vendor_app vendor_file:dir create_dir_perms;
allow vendor_app vendor_file:file create_file_perms;

allow vendor_app audioserver_service:service_manager find;
allow vendor_app cameraserver_service:service_manager find;
allow vendor_app drmserver_service:service_manager find;
allow vendor_app mediaserver_service:service_manager find;
allow vendor_app mediaextractor_service:service_manager find;
allow vendor_app mediacodec_service:service_manager find;
allow vendor_app mediadrmserver_service:service_manager find;
allow vendor_app persistent_data_block_service:service_manager find;
allow vendor_app radio_service:service_manager find;
allow vendor_app surfaceflinger_service:service_manager find;
allow vendor_app app_api_service:service_manager find;
allow vendor_app system_api_service:service_manager find;
allow vendor_app vr_manager_service:service_manager find;

我在其中添加了一项文件上下文配置：

###################################
# persist files
#
/persist(/.*)?                                                      u:object_r:persist_file:s0
/persist/vendor(/.*)?                                               u:object_r:vendor_file:s0

在 /persist 分区上，我创建了一些目录结构，以包含具有适当权限的文件夹，以便在其中添加一些文件。

# ls -Zal /persist/vendor/                                            
total 56
drwxrwxrwx  5 persist   persist   u:object_r:vendor_file:s0  4096 2017-08-03 22:27 .
drwxrwx--x 16 system    system    u:object_r:persist_file:s0 4096 2017-08-01 16:24 ..
drwxrwxrwx  2 profile   profile   u:object_r:vendor_file:s0  4096 2017-08-04 13:34 profile
drwxrwxrwx  2 provision provision u:object_r:vendor_file:s0  4096 2017-08-04 13:34 provisioning
drwxrwxrwx  2 updater   updater   u:object_r:vendor_file:s0  4096 2017-08-04 13:34 updater

我知道find-服务规则正在发挥作用，因为我能够以强制模式启动我的应用程序，并且不会收到任何对此的投诉。我还可以访问 /persist 目录{ 搜索 }在有关规则允许的情况下持久文件：目录.

一旦我尝试编写一个新文件，例如/坚持/供应商/更新程序/测试 to the /persist目录中，我从auditd 收到错误消息：

08-04 16:34:29.269  4108  4108 W .permissiontest: type=1400 audit(0.0:27): avc: denied { write } for name="updater" dev="mmcblk0p44" ino=55 scontext=u:r:vendor_app:s0:c512,c768 tcontext=u:object_r:vendor_file:s0 tclass=dir permissive=0

该错误当然会被audit2allow转换为以下规则：

#============= vendor_app ==============
allow vendor_app vendor_file:dir write;

As write是的成员创建目录权限，它实际上应该在那里。我还尝试添加由创建的行审核2允许 to my 供应商.te没有任何成功。

请注意，写入更新程序还涉及search on 持久文件 and search on 供应商文件这两者似乎都可以正常工作。

有没有人有任何建议，如何正确调试，甚至可能解决这个问题？我已经研究这个问题两天了，这让我发疯。

EDIT:

啊。 /persist 当然是挂载可写的：

# mount | grep persist
/dev/block/bootdevice/by-name/persist on /persist type ext4 (rw,seclabel,nosuid,nodev,relatime,nodelalloc,errors=panic,data=ordered)

EDIT 2:

正如 Paul Ratazzi 所要求的，我已经扫描了 sepolicy 文件和实际加载到内核中的版本，以了解我的规则是否存在。

$ sesearch -A -s vendor_app -t vendor_file policy 
allow vendor_app vendor_file:dir { rename search setattr read lock create reparent getattr write ioctl rmdir remove_name open add_name };
allow vendor_app vendor_file:file { rename setattr read lock create getattr write ioctl unlink open append };

因此它们实际上已正确部署到设备上。

好吧，经过一番挖掘，看来我终于找到了答案。为了也许能让那些遇到同样问题的人在一些令人头疼的日子里免遭困扰，这里是解决方案：

Besides MAC（强制访问控制）Android 上也有 SElinuxMLS（多级安全）.

虽然 MAC 在某种程度上有所描述Android SELinux 概念，关于MLS的信息只是非常简短和含蓄地提到：

在 SELinux 中，标签采用以下形式：user:role:type：mls_level，其中类型是访问决策的主要组成部分，可以通过构成标签的其他部分组件进行修改。

因此，我的 Android 应用程序在 MLS 级别（由 c512、c768 表示）运行，可以读取 /persist 上的文件，但不能写入它们。因此，我的应用程序需要获得 MLS 级别才能正确访问这些文件。

我（目前）已通过将自定义标签更改为

type vendor_app, domain, mlstrustedsubject;

这使我的应用程序值得信赖。这解决了问题，但授予了对我的应用程序的大量访问权限。因此，更好的选择是将目标的安全级别设置为授予对我的应用程序的读写访问权限的级别。

所以这基本上是到目前为止这个问题的解决方案（虽然还没有完成）。