[Xposed General] Tungstwenty:
I have been able to dump most of the info in a very verbose format.

The binary format doesn't allow the reconstruction of the source file because many of the "wildcard" entries are expanded to individual ones for speed. Anyway, for quick search of rules on the text it's much simpler to grep for the intended token instead of needing to e.g. cope with "*", "~{ ... }", etc. instead of say "read" or "write".

I still need to change the code so it runs elsewhere, but here are the dumps of 3 policies:

- AOSP, 4.4.2 tag, compiled with the ENG configuration

- my stock Xperia Z 4.4.2

- S5 (shared here, don't know the exact ROM)

From AOSP to the Xperia Z the differences aren't that big.

The "su" type is removed, as well as the few entries related with allowing shell to run it, automatically doing the transition to the su type, and the permissions of something running with su context.

Apart from that, only additional entries and permissions specific to the Xperia Z.

In both of them the "init" type is set to permissive, which for Xposed means that having /system/bin/app_process assigned to context "u: object_r:system_file:s0" instead of "u: object_r:zygote_exec:s0" makes everything work fine.

Since there is no type transition from init to system_file:file, zygote will run with "u:r:init:s0" and do everything it wants since init is permissive. Denied avc messages could pop up on dmsg that might not be triggered if the zygote context was being used, but they're merely informative.

Changing app_process to zygote_exec would make the transition happen from "init" to "zygote", and then no access could be done to /data/data/* since 1) zygote isn't defined as permissive and 2) there isn't any allow command to "app_data_file:file { ... }" either to zygote directly, or none of the attribute it has ("mlstrustedsubject" and "domain").

Now, on the S5 there are lots of differences against AOSP.

First of all, none of the types (including init) are permissive. Access will fail unless explicit grants exist.

init can execute system_file:file objects (through one of its attributes such as domain) and there's still no type_transition for that, so app_process will remain as init.

Even though init is no longer permissive, it will be able to read /data/data/* app_data_file objects, since it's (still) declared with the "unconfineddomain" and there's now a rule to allow unconfineddomain access to app_data_file:file.

As for the other permissions of init vs zygote, there are *a lot* of additional entries for zygote.

To query:

TYPES=`grep "^type zygote," *.dump | cut -c6- | sed "s/, /|/g" | sed "s/;//g"`
grep -E "^allow ($TYPES) " *.dump | cut -d" " -f3 | sort | uniq
grep -E "^type_transition ($TYPES) " *.dump | cut -d" " -f3-

Repeat for "init" instead of "zygote" and compare.

The good news for Xposed is that zygote now has access to app_data_files:

$ grep -E "^allow ($TYPES) " *.dump | cut -d" " -f3- | sort | uniq | grep "^app_data_file:"
app_data_file:blk_file { ioctl read write create getattr setattr lock append unlink link rename open }
app_data_file:chr_file { ioctl read write create getattr setattr lock append unlink link rename open }
app_data_file:dir { ioctl read write create getattr setattr unlink link rename add_name remove_name reparent search rmdir open }
app_data_file:fifo_file { ioctl read write create getattr setattr lock append unlink link rename open }
app_data_file:file { ioctl read write create getattr setattr lock append unlink link rename execute open }
app_data_file:file { ioctl read write create getattr setattr lock append unlink link rename open }
app_data_file:lnk_file { ioctl read write create getattr setattr lock append unlink link rename open }
app_data_file:sock_file { ioctl read write create getattr setattr lock append unlink link rename open }

Configuration files can be read, and the log can be written from zygote.

Regular apps will have type "untrusted_app" (from seapp_contexts) and its permissions for app_data_file (where mod's configurations are):

$ TYPES=`grep "^type untrusted_app," *.dump | cut -c6- | sed "s/, /|/g" | sed "s/;//g"`
$ grep -E "^allow ($TYPES) " *.dump | cut -d" " -f3- | sort | uniq | grep "^app_data_file:"
app_data_file:blk_file getattr
app_data_file:chr_file getattr
app_data_file:dir { ioctl read getattr search open }
app_data_file:dir { ioctl read write create getattr setattr unlink link rename add_name remove_name reparent search rmdir open }
app_data_file:fifo_file { ioctl read getattr lock open }
app_data_file:fifo_file { ioctl read write create getattr setattr lock append unlink link rename open }
app_data_file:fifo_file getattr
app_data_file:file { ioctl read getattr lock execute execute_no_trans open }
app_data_file:file { ioctl read write create getattr setattr lock append unlink link rename open }
app_data_file:file getattr
app_data_file:lnk_file { ioctl read getattr lock open }
app_data_file:lnk_file { ioctl read write create getattr setattr lock append unlink link rename open }
app_data_file:lnk_file getattr
app_data_file:sock_file { ioctl read write create getattr setattr lock append unlink link rename open }
app_data_file:sock_file { ioctl read write getattr lock append open }
app_data_file:sock_file getattr

so they should also be able to load their configurations and write to the xposed log (TBC)

I also noticed this and this commit on the master of sepolicy, suggesting that this sort of changes will indeed make it to the next release.

Chainfire had already posted along those lines here, about the removal of the execute permission for files other than rootfs, system_file or exec_type (such as scripts on /data/data/*.

[MENTION=631273]Chainfire[/MENTION], perhaps running "chcon u: object_r:system_file:s0 ..." on the script file prior to its execution might be a workaround? :confused:

EDIT: Just noticed that you already mention this kind of approach in section "Android 4.5" of your How-to-SU guide.