我的自定义selinux策略似乎被android系统忽略 [英] My custom selinux policies seem to be ignored by android system
问题描述
在使自定义selinux策略在基于AOSP的Android 7.1.2(更精确地基于索尼开放设备树)上正确运行方面，我遇到了一些麻烦.
I have some trouble on getting custom selinux policies running properly on an AOSP based Android 7.1.2 (more precisely based on sony open devices tree).
我的问题是审核日志不断告诉我有关我实际添加的缺少文件访问规则的信息.我还复制了audit2allow创建的规则到我的策略文件中，但是即使那些规则也无法正常工作.
My problem is that the audit logs keep telling me about missing file access rules that I actually added. I also copied rules that audit2allow has created to my policy files, but even those do not properly work.
所以，让我们深入研究细节:
So, let's dig into the details:
我创建了一个名为 vendor_app 的自定义域.该域根据其签名分配给应用.我在 mac_permissions.xml 中添加了一个条目，以分配seinfo字段 vendor .在 seapp_contexts 中，我分配 vendor_app 域，如下所示:
I created a custom domain called vendor_app. This domain is assigned to an app based on its signature. I have added an entry to the mac_permissions.xml to assign the seinfo field vendor. In seapp_contexts I assign the vendor_app domain like this:
user=_app seinfo=vendor domain=vendor_app type=app_data_file levelFrom=user
我的应用已在vendor_app上下文中正确启动:
My app is properly started in the vendor_app context:
# 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 中文件的读/写访问权限.为了创建必要的规则，我在设备目录中的 sepolicy 文件夹中添加了一个名为 vendor.te 的文件，其内容如下:
So, now for the part that does not work at all. An app running in the vendor_app context shall get read/write access to files in /persist/vendor. To create the nessesary rules, I added a file called vendor.te to the sepolicy folder in the device directory with the followin content:
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 配置中添加了一个条目:
And I have added one entry in the file_contexts configuration:
###################################
# persist files
#
/persist(/.*)? u:object_r:persist_file:s0
/persist/vendor(/.*)? u:object_r:vendor_file:s0
在/persist分区上，我创建了一些目录结构，以使文件夹具有适当的权限以在其中添加一些文件.
On the /persist partition, I created some directory structure to have folders with appropriate permissions to add some files there.
# 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目录.
I know that the find-rules for the services are working, as I am able to start my app in enforcing mode and do not get any complaints about that. I am also able to access the /persist directory for { search } as allowed by the rule regarding persist_file:dir.
当我尝试将/persist/vendor/updater/test 之类的新文件写入/persist 目录时，我收到来自auditd的错误消息:
As soon as I try writing a new file like /persist/vendor/updater/test to the /persist directory, I get error messages from 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转换为以下规则:
That error is of course converted by audit2allow to the following rule:
#============= vendor_app ==============
allow vendor_app vendor_file:dir write;
由于 write 是 create_dir_perms 的成员，因此它实际上应该存在.我还尝试将 audit2allow 创建的行添加到我的 vendor.te 中，但没有成功.
As write is a member of create_dir_perms, it actually should be there. I have also tried adding the line created by audit2allow to my vendor.te without any success.
请注意，写入更新程序还涉及 persist_file 上的 search 和 vendor_file 上的 search 工作没有任何问题.
Please notice that writing to updater also involves search on persist_file and search on vendor_file which both seem to work without any problems.
有没有人提供任何建议，如何正确调试它甚至是针对此问题的任何解决方案?我已经研究了两天了，这真让我发疯.
Has anyone any advice, how to debug that properly or maybe even any solution for this problem? I have been digging on this for two days now and it's driving me nuts.
啊./persist当然是可写的:
Ah. /persist is of course mounted writable:
# mount | grep persist
/dev/block/bootdevice/by-name/persist on /persist type ext4 (rw,seclabel,nosuid,nodev,relatime,nodelalloc,errors=panic,data=ordered)
按照Paul Ratazzi的要求，我还扫描了sepolicy文件以及实际加载到内核中的版本，以查看是否存在我的规则.
As Paul Ratazzi has asked, I have scanned the sepolicy file and the version actually loaded into the kernel for the presence of my rules as well.
$ 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 };
因此它们实际上已正确部署到设备上.
So they are infact deployed to the device properly.
推荐答案
好吧，经过进一步的挖掘，看来我终于找到了答案.为了避免某人在脑筋急转弯的日子里遇到相同的问题，这里提供了解决方案:
Well, after some more digging, it looks like I finally found the answer. To maybe save someone running into the same problem some brain-hurting days, here is the solution:
除了 MAC(强制访问控制)，Android上的SElinux也
Besides MAC (Mandatory Access Control) SElinux on android also MLS (Multi-Level Security).
虽然 Android SELinux概念中以某种方式描述了MAC，但是有关MLS的信息是仅提及非常简短而隐含:
While MAC is somehow described in the Android SELinux concepts, the information about MLS is only mentioned very brief and implicitly:
在SELinux中，标签的格式为:user:role:type: mls_level ，其中，类型是访问决策的主要组成部分，其他部分可以通过修改这些组成部分来进行访问标签上.
In SELinux, a label takes the form: user:role:type:mls_level, where the type is the primary component of the access decisions, which may be modified by the other sections components which make up the label.
因此，发生的事情是我的Android应用运行在MLS级别(由c512，c768表示)，该级别可以读取/persist上的文件，但不能写入它们.因此，需要做的是，我的应用获得了MLS级别才能正确访问这些文件.
So, what happens is that my Android app runs in a MLS level (indicated by c512,c768) that can read files on /persist but not write them. So what needs to happen is that my app gets an MLS level to properly access those files.
(暂时)我将自己的自定义标签更改为
I have (for now) archived this by changing my custom label to
type vendor_app, domain, mlstrustedsubject;
这使我的应用程序受信任.这可以解决问题，但可以授予我的应用程序很多访问权限.因此，更好的选择是将目标的安全级别设置为授予对我的应用程序的读写访问权限的级别.
which makes my app trusted. This fixes the problem but grants a whole lot of access to my app. Thus a better option would be to lover the security level of the destination to a level that grants read and write access to my app.
因此，到目前为止，这基本上是解决此问题的方法(虽然尚未完成).
So this is basically the solution for this problem up to now (while still not yet complete).
这篇关于我的自定义selinux策略似乎被android系统忽略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
