FORUMS
Remove All Ads from XDA

[AOSP] sepolicy patch for Marshmallow ROMs

3,682 posts
Thanks Meter: 53,646
 
Post Reply Email Thread
After a bit of tinkering and some insight from Chainfire and imoseyon i was finally able to get SuperSU working on AOSP roms without being permissive or having to use Chainfire's prebuilt sepolicy

sepolicy patch is here: https://github.com/PureNexusProject/...e4c1c35d3e3c1a
The Following 27 Users Say Thank You to BeansTown106 For This Useful Post: [ View ]
 
 
26th November 2015, 10:25 PM |#2  
Chainfire's Avatar
Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 83,892
 
Donate to Me
More
Stickied.
The Following 10 Users Say Thank You to Chainfire For This Useful Post: [ View ]
27th November 2015, 05:13 AM |#3  
WarningHPB's Avatar
Member
Thanks Meter: 12
 
More
sorry to be that guy, but how does this affect the average joe?

does it mean theres going to be a new version of supersu with this or does this mean that custom rom makers can use this patch to make there roms not need the the custom boot.img?
The Following 3 Users Say Thank You to WarningHPB For This Useful Post: [ View ] Gift WarningHPB Ad-Free
27th November 2015, 02:37 PM |#4  
Chainfire's Avatar
Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 83,892
 
Donate to Me
More
Quote:
Originally Posted by WarningHPB

sorry to be that guy, but how does this affect the average joe?

It doesn't, this is for ROM devs only, they know what to do with this.
The Following 5 Users Say Thank You to Chainfire For This Useful Post: [ View ]
27th November 2015, 09:17 PM |#5  
Member
Flag Woodridge
Thanks Meter: 23
 
Donate to Me
More
Quote:
Originally Posted by Chainfire

It doesn't, this is for ROM devs only, they know what to do with this.

Welcome back! Hope you had a good break.
The Following User Says Thank You to vladashram For This Useful Post: [ View ] Gift vladashram Ad-Free
28th November 2015, 09:39 AM |#6  
BeansTown106's Avatar
OP Recognized Developer / Contributor
Flag BeanTown USA
Thanks Meter: 53,646
 
Donate to Me
More
Quote:
Originally Posted by Chainfire

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
The Following 8 Users Say Thank You to BeansTown106 For This Useful Post: [ View ]
29th November 2015, 11:44 AM |#7  
Chainfire's Avatar
Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 83,892
 
Donate to Me
More
Quote:
Originally Posted by BeansTown106

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

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.
The Following 6 Users Say Thank You to Chainfire For This Useful Post: [ View ]
9th December 2015, 12:43 PM |#8  
Chainfire's Avatar
Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 83,892
 
Donate to Me
More
@BeansTown106

Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
The Following 4 Users Say Thank You to Chainfire For This Useful Post: [ View ]
10th December 2015, 09:35 PM |#9  
BeansTown106's Avatar
OP Recognized Developer / Contributor
Flag BeanTown USA
Thanks Meter: 53,646
 
Donate to Me
More
Quote:
Originally Posted by Chainfire

@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
The Following User Says Thank You to BeansTown106 For This Useful Post: [ View ]
20th December 2015, 06:57 PM |#10  
Chainfire's Avatar
Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 83,892
 
Donate to Me
More
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.
The Following 4 Users Say Thank You to Chainfire For This Useful Post: [ View ]
3rd January 2016, 02:01 PM |#11  
danieldmm's Avatar
Senior Member
Flag France
Thanks Meter: 8,437
 
Donate to Me
More
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...
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes