[Xposed General] rovo89:
Hey developers,

I would like to ask for your advise regarding SELinux. As you have probably read, there sepolicy in AOSP gets stricter and stricter. I think that for most users (especially corporate/non-geeky ones), this is a good step, but I don't want to discuss the sense here. It's a fact that restrictions will be stricter, so let's see what we as developers can do about this.

Note that disabling SELinux or setting it to permissive mode would be the obvious solution, but that's not always possible and has a wider impact on the system. So it's not something I would like to discuss here either.

So, Xposed and modules are accessing a couple of different files:

1) Module list - must be readable by the Zygote process (preferably by others as well), must be read- and writeable by the Xposed Installer app

2) Configuration files for the framework (such as "disable resources" etc.) - same as above

3) Configuration files for modules - must be (at least) readable by Zygote, system_server and every app, must be writable by a normal app (the module's UI)

4) Log - must be writable by Zygote, system_server and every app, must be readable by the Xposed Installer app (at least)

5) Upcoming libxposed_<runtime>.so files - must be loadable by at least the Zygote process (via dlopen), must be writable by the installer (preferably directly, otherwise via su)

Currently, only 5) seems to be an issue. That's mainly because the installer doesn't execute "restorecon" on app_process after replacing it, due to which it stays in context u:object_r:system_file:s0 instead of u:object_r:zygote_exec:s0 due to which the process runs as u:r:init:s0. This was accidental, but effective. I assume that it will no longer work properly in the future, and even now it already caused issues on some devices. So any solutions have to work for the correct zygote context.

Some things I have been wondering about:

- Would it be possible to add new policies to any ROM without recompiling it/flashing a new kernel/things like that? If so, then maybe the missing permissions could simply be added.

- Could the app which creates a configuration file also set its context? If so, it would be required to find a context which is less restrictive.

- In case changing the files' context is part of the solution, what is the risk of this change getting reverted? It seems that there is at least some code that triggers a relabelling: https://github.com/android/platform...a/com/android/server/pm/SELinuxMMAC.java#L388

- Would it be less risky to use something like /data/xposed/ or /data/system/xposed/ instead? I previously used the former, but got rid of it to avoid the need to clean up and because SELinux blocked writing to files there (with the default context).

I also had some ideas like using a shared memory segment or a socket to have some kind of daemon in the Zygote process (or a fork of it) to exchange content for configuration files. It would obviously have to store the data somewhere for the next restart. Configuration read/writes would have to be sent to the daemon. Might need changes in all modules using it, or maybe could be addressed globally with some hooks. That would be a bit like XPrivacy's service, which however is running in the system_server process only and therefore not available in Zygote.

Anyway, if you know a bit about how SELinux works on Android and can share some ideas or advise about the points mentioned above, please do so. This could be very crucial for Xposed support, even in the near future. Thanks!