My selinux user policies seem to be ignored by Android system

Question

I have some problems with the selinux user policies working correctly on Android 7.1.2 based on AOSP (more precisely based on the tree of open sony devices).

My problem is that audit logs continue to tell me about the file access rules that I actually added. I also copied the rules that audit2allow created for my policy files, but even those that don't work properly,

So paste in the details:

I created my own domain called vendor_app. This domain is assigned to the application based on its signature. I added an entry to the mac_permissions.xml file to assign a provider to the seinfo field. In seapp_contexts, I assign the vendor_app domain as follows:

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

My application runs correctly in the context of 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 

So now for the part that doesn't work at all. An application running in the context of vendor_app must have read / write access to files in / persist / vendor. To create the necessary rules, I added a file called vendor.te to the sepolicy folder in the device directory with the contents of followin:

 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; 

And I added one entry to the file_contexts configuration:

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

In the / persist section, I created some directory structure to have folders with the 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 

I know that the search rules for services work, since I can run the application in enforcement mode and not receive any complaints about it. I can also access the / persist directory for {search}, as permitted by the rule regarding persist_file: dir.

As soon as I try to write a new file, for example / 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 

This error, of course, is converted using audit2allow to the following rule:

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

Since the entry is a member of create_dir_perms, it should be there. I also tried adding the string generated by audit2allow to my vendor.te without any success.

Note that writing to updater also includes searching on persist_file and searching on vendor_file, which seems to work without problems.

Does anyone have any tips on how to debug this correctly, or perhaps even any solution to this problem? I have been digging this for two days, and it drives me crazy.

EDIT:

Ah. / Persist, of course, is writable:

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

As Pavel Ratazzi asked, I looked at the sepolicy file and the version actually downloaded to the kernel for my rules.

 $ 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 }; 

Thus, they are effectively embedded in the device.

Answer 1

Well, after some more digging, it seems like I finally found the answer. To save someone who is facing the same problem, some days that hit the brain are the solution:

In addition to MAC (mandatory access control) SElinux on android also has MLS (multi-level security) .

While the MAC is somehow described in the Android SELinux concept , MLS information is only mentioned very briefly and implicitly:

In SELinux, the label takes the form: user: role: type: mls_level , where type is the main component of access decisions that can be changed by other components of the partitions that make up the label.

So what happens is that my Android application runs at the MLS level (indicated by c512, c768), which can read files in / persist but not write them. So what should happen is that my application gets the MLS level for proper access to these files.

I (for now) archived this by changing my own label to

 type vendor_app, domain, mlstrustedsubject; 

which makes my application reliable. This fixes the problem but gives a lot of access to my application. Thus, the best option would be to increase the recipient's security level to the level that provides read and write access to my application.

So this is basically the solution to this problem so far (not yet completed).