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

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 policyallow 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也 MLS(多级安全性).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 totype 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系统忽略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！ 上岸，阿里云！