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

Question

我在基于AOSP的Android 7.1.2(更准确地说是基于sony开放设备树)上正确运行自定义selinux策略时遇到一些麻烦.

我的问题是审计日志不断告诉我我实际添加的文件访问规则丢失.我还将audit2allow创建的规则复制到我的策略文件中,但即使那些规则也没有正常工作.

那么,让我们深入了解细节:

我创建了一个名为vendor_app的自定义域.此域根据其签名分配给应用程序.我在mac_permissions.xml中添加了一个条目来分配seinfo字段供应商.在seapp_contexts中,我像这样分配vendor_app域:

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

我的应用程序在vendor_app上下文中正确启动:

# 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

所以,现在对于根本不起作用的部分.在vendor_app上下文中运行的应用程序将获得/ persist/vendor中文件的读/写访问权限.为了创建nessesary规则,我将一个名为vendor.te的文件添加到设备目录中的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;

我在file_contexts配置中添加了一个条目:

###################################
# 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

我知道服务的查找规则正在运行,因为我能够以强制模式启动我的应用程序并且不会对此有任何抱怨.我也能够访问有关persist_file:dir的规则所允许的{search}的/ 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;

由于write是create_dir_perms的成员,它实际上应该在那里.我也尝试将audit2allow创建的行添加到我的vendor.te中,但没有成功.

请注意,写作也更新涉及到搜索上persist_file和搜索上vendor_file这似乎都没有任何问题的工作.

有没有人有任何建议,如何正确调试,甚至可能解决这个问题？我现在已经挖了两天了,这让我疯了.

编辑:

啊./ persist当然是可写的:

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

编辑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 };

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

Answer 1

好吧，经过更多的挖掘，看来我终于找到了答案。为了避免某人在脑筋急转弯的日子里遇到相同的问题，这里提供了解决方案：

除了Android上的MAC（强制性访问控制） SElinux之外，还有MLS（多级安全性）。

尽管在Android SELinux概念中以某种方式描述了MAC ，但是关于MLS的信息只是非常简短而隐含地提及：

在SELinux中，标签的形式为：user：role：type：mls_level，其中类型是访问决策的主要组成部分，可以由组成标签的其他部分组件修改。

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

我已经（暂时）将自定义标签更改为

type vendor_app, domain, mlstrustedsubject;

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

因此，到目前为止，这基本上是解决此问题的解决方案（尽管尚未完成）。