[AOSP] sepolicy patch for Marshmallow ROMs

BeansTown106

Inactive Recognized Developer
Dec 22, 2011
3,694
54,411
0
BeanTown USA
Stickied.
Thanks :) after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow

Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.

thanks in advance :good:
 

Chainfire

Moderator Emeritus / Senior Recognized Developer -
Oct 2, 2007
11,440
87,679
263
www.chainfire.eu
Thanks :) after including this in my AOSP builds i have noticed a few things, certain "root" app still dont function and get selinux denials. i originally had noticed this with logcat extreme. i was getting read and write denials on logd so i did an audit2allow on my sepolicy and came up with the following allow

Code:
#============= logd ==============
allow logd init:fifo_file { read write };
i did a quick google search on this and came up with https://gist.github.com/poliva/fc5b7402bde74be27518 which is apparently an sediff of your sepolicy, which is heavily modified beyond just what i had for supersu to work in enforcing for aosp roms. so i guess my real question is do us "AOSP" devs have to update our sepolicys with these 300+ additions to get all current root apps working or is this something that you can overcome in an update to SuperSU.

thanks in advance :good:
There is no such thing now as "all current root apps working".

If SuperSU's deamon can be launched, and it can in turn launch the supolicy tool, most of the rules from the diff will be modified by SuperSU as needed.

What your patch needs to do (and you have already done) is make sure SuperSU can be launched in the right context, and can modify the sepolicy. You do not need to implement those 300+ additions - it will be done at boot automagically.

As for those additions themselves, they are primarily needed to:
- make sure SuperSU can work, internal communications between the different processes and such
- make processes running as the "init" context (where root apps run by default) as powerful as possible
- specifically "allow" a number of things that would otherwise still work, but would be logged (everything that starts with "allow init" or "allow recovery")

Now, even with the above, still not everything works out of the box. Everything that goes from "init" to "non-init" context should already work, but going from "non-init" context to "init" may not. In your example case, we go from "logd" to "init", which isn't specifically allowed. Often apps can be fixed to work around an issue such as this.

Generally speaking, the solution is not to fix the source sepolicy or the supolicy tool, the solution is for the "logcat extreme" app to run the following at launch (as documented in How-To SU):

Code:
supolicy --live "allow logd init fifo_file { read write }"
In this specific case, maybe it could be added to supolicy, it depends on what exactly generates the audit. If it's a simple logcat command, it's a candidate for inclusion. The problem might even be solved by switching contexts rather than modifying any SELinux policies. But that is something for the app developer to figure out.

In either case, it is not something you need to fix in the AOSP patches. Those already do what they need to do.

Since they started doing SELinux Enforcing though, the policies in AOSP have generally been a tad stricter than on retail devices (this was specifically the case during 4.4 days). This may lead to you sometimes having to add/remove a rule manually somewhere that was not added to SuperSU yet. It could happen, but it's unlikely, probably temporary, and it probably should not go into this AOSP patch.

A note on pof's sediff, I'm not sure it was done cleanly, as I see some modifications in there that are not done by supolicy. Either way, such a post is informative, not leading, as supolicy may do more or less modifications depending on various runtime variables (such as Android version). Additionally, due to context names and availabilities changing between Android versions, any rule modification referencing a context not available in the to-be-patched sepolicy will not be applied, and thus will not show up in an sediff.
 

BeansTown106

Inactive Recognized Developer
Dec 22, 2011
3,694
54,411
0
BeanTown USA
@BeansTown106

Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
thanks for the description above now i understand. have never developed a root app so i had not read that part of how to su, but it makes perfect sense that the root apps would handle the denials live via your supolicy :)

as for system less root i have not tried that yet but i will give it a shot tonight, and report back, i know some people in my ROM thread have used system less root. but i am not sure if you had packaged your sepolicy in the install script for 2.61+ and if it is overwriting mine in the kernel, if that is the case i will modify the installation to not patch the sepolicy and see if it works with my pre compiled one based on the source above
 
  • Like
Reactions: Chainfire

Chainfire

Moderator Emeritus / Senior Recognized Developer -
Oct 2, 2007
11,440
87,679
263
www.chainfire.eu
Starting 2.64, I think this addition to init.te is all that is needed:

Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.

Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
 

danieldmm

Senior Member
Dec 18, 2008
5,178
12,038
263
France
the link in OP its no longer working...

Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
#   allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
 
Last edited:

BeansTown106

Inactive Recognized Developer
Dec 22, 2011
3,694
54,411
0
BeanTown USA
Starting 2.64, I think this addition to init.te is all that is needed:
Code:
allow init kernel:security load_policy;
Confirmation needed though. The original patch will also work with 2.64, and the ZIP installer should default to /system installation mode.

Of course, this also requires that /system isn't verified by dm-verity, and init reloads sepolicy from the standard /data/security/current location.
will build and test with only load policy enabled, is this for system, and systemless root?

the link in OP its no longer working...

Also in CM13 tree we have:
Code:
# Reload policy upon setprop selinux.reload_policy 1.
# Note: this requires the following allow rule
#   allow init kernel:security load_policy;
and over my builds have no problem with SuperSU system less...
updated link, so your saying systemless supersu works with no selinux modifications?
 

Jugehuge

Member
Jan 2, 2017
35
13
0
Link in OP its no longer working...

Is there any actual guide how to add SU directly to AOSP build. I have found bits and pieces but those are mainly 4.x releases.
I'm using Android M release and quite much struggling to get it working.
 

Jugehuge

Member
Jan 2, 2017
35
13
0
I have tried to make SU default on AOSP 6.0 by using this guide.
http://forum.khadas.com/t/gapps-and-su-on-soc/118/3
I'm using user build and enabled selinux permissive on that.
i have made also ro.secure=0 ro.debuggable=1 and security.perf_harden=0 (Not sure if needed)
I have also modified to change the su permissions in fs_config.c
I managed to get this work so that when flashing rom SuperSu ask for updating su binary and after that su works.
but i then cleaned work area to verify build by deleting out dir and recompiled. No go anymore.
Why it's so hard to add su by default on AOSP rom. I woud like to have it by default so i would not need to do any tricks everytime i flash new rom.