Related
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...mmit/0f5072de4580a5db7348917e77e4c1c35d3e3c1a
Stickied.
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?
WarningHPB said:
sorry to be that guy, but how does this affect the average joe?
Click to expand...
Click to collapse
It doesn't, this is for ROM devs only, they know what to do with this.
Chainfire said:
It doesn't, this is for ROM devs only, they know what to do with this.
Click to expand...
Click to collapse
Welcome back! Hope you had a good break.
Chainfire said:
Stickied.
Click to expand...
Click to collapse
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:
BeansTown106 said:
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:
Click to expand...
Click to collapse
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
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Chainfire said:
@BeansTown106
Have you checked by any chance if this patch is enough to allow 2.61 (systemless) to work still ?
Click to expand...
Click to collapse
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
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 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...
Chainfire said:
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.
Click to expand...
Click to collapse
will build and test with only load policy enabled, is this for system, and systemless root?
danieldmm said:
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...
Click to expand...
Click to collapse
updated link, so your saying systemless supersu works with no selinux modifications?
BeansTown106 said:
updated link, so your saying systemless supersu works with no selinux modifications?
Click to expand...
Click to collapse
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
danieldmm said:
Over my builds yes, no issues at all in cm13, although my kernel it's in permissive mode. Maybe it's why it works all good?
Enviado do meu A0001 através de Tapatalk
Click to expand...
Click to collapse
that is why, these patchs are to allow you to run in enforcing
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Garzla said:
I dont know if a should post here this question: there is any way to fix this problem with the rom already installed?
Thanks
Click to expand...
Click to collapse
Try the following. It works for me when needed...
http://forum.xda-developers.com/showthread.php?t=3574688
Thank you for your work!
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.
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.
It reminds me of Korean dramas ,
Perhaps someone can clarify for me...
I use Magisk and I've noticed that it was recently updated and there are mentionings about SELinux/sepolicy and pseudo enforced, etc. in the changelog.
Whenever I run SambaDroid it will fail to start unless I open the SELinuxModeChanger app and change the mode to Permissive first, which of course ruins SafetyNet, so I can't just leave it in that mode all the time.
I have to go back and change it to Enforcing when I am done.
An extra step I'm hoping won't be required in the future. Perhaps on a per-app basis like MagiskHide.
Should the recent changes to Magisk allow me to run SambaDroid without having to manually change the SELinux Mode?
If so, it doesn't work yet, but maybe I am misunderstanding the changelog references.
andrewsfm said:
Perhaps someone can clarify for me...
I use Magisk and I've noticed that it was recently updated and there are mentionings about SELinux/sepolicy and pseudo enforced, etc. in the changelog.
Whenever I run SambaDroid it will fail to start unless I open the SELinuxModeChanger app and change the mode to Permissive first, which of course ruins SafetyNet, so I can't just leave it in that mode all the time.
I have to go back and change it to Enforcing when I am done.
An extra step I'm hoping won't be required in the future. Perhaps on a per-app basis like MagiskHide.
Should the recent changes to Magisk allow me to run SambaDroid without having to manually change the SELinux Mode?
If so, it doesn't work yet, but maybe I am misunderstanding the changelog references.
Click to expand...
Click to collapse
The update in v11 you're talking about should be able to hide permissive SELinux from SafetNet. In other words: you should be able to leave SELinux permissive and still pass SafetyNet with the help of Magisk Hide.
Didgeridoohan said:
The update in v11 you're talking about should be able to hide permissive SELinux from SafetNet. In other words: you should be able to leave SELinux permissive and still pass SafetyNet with the help of Magisk Hide.
Click to expand...
Click to collapse
Ahh okay, I get it. Just tested it now and it works exactly like you described. It wouldn't pass SafetyNet before on the previous version but apparently does now after the upgrade when left in permissive. Thanks!
Nevermind my last post... Picked up the phone again, and opened SELinuxModeChanger and found that it had reverted back to enforcing on its own. Changed it to permissive, and then went back to Magisk Manager, and SafetyNet fails until I revert the setting back to enforcing. Seems like it works the first time, and then stops?
andrewsfm said:
Nevermind my last post... Picked up the phone again, and opened SELinuxModeChanger and found that it had reverted back to enforcing on its own. Changed it to permissive, and then went back to Magisk Manager, and SafetyNet fails until I revert the setting back to enforcing. Seems like it works the first time, and then stops?
Click to expand...
Click to collapse
Hmm... Interesting. I think I'll do some tests myself.
andrewsfm said:
Nevermind my last post... Picked up the phone again, and opened SELinuxModeChanger and found that it had reverted back to enforcing on its own. Changed it to permissive, and then went back to Magisk Manager, and SafetyNet fails until I revert the setting back to enforcing. Seems like it works the first time, and then stops?
Click to expand...
Click to collapse
Ok. I've tested and it seems to work as expected.
What I did was add a file in /magisk/.core/post-fs-data.d named 08setperm (doesn't matter what the file is named). In that file I added:
#!/system/sh
setenforce 0
This way SELinux is set to permissive at boot.
Disabled Magisk Hide, rebooted and verified that SELinux now was set to permissive on boot (typed getenforce in Teminal Emulator).
Enabled Magisk Hide again and voila! Typing getenforce in Terminal emulator now reported Enforcing and SafetyNet passed.
No idea if this will make SambaDroid work though...
I found a way to somewhat replicate what I am experiencing.
You'll need SELinuxModeChanger (SELMC) to see if you get the same results.
Although I'm wondering if it may be the cause of the problem...
Open recent apps and clear everything out.
Open SELMC and change to permissive.
Hit the home button.
Launch Magisk Manager and check SN. Should pass.
Hit the home button.
Clear recent apps.
Open SELMC, and it's back to enforcing.
Change back to permissive.
Hit the home button.
Re-launch MM and check SN, and it comes back CTS fail.
If you stay in MM and wait for a while, occasionally clicking check SN, eventually, it'll pass without changing anything.
If you change tasks over to SELMC, you'll see it's still in permissive as well.
It appears the transition from enforcing to permissive causes SN to fail for a while, and SELMC reverts back to enforcing if cleared from recent tasks, and re-activating it causes SN to fail for a period of time?
andrewsfm said:
I found a way to somewhat replicate what I am experiencing.
You'll need SELinuxModeChanger (SELMC) to see if you get the same results.
Although I'm wondering if it may be the cause of the problem...
Open recent apps and clear everything out.
Open SELMC and change to permissive.
Hit the home button.
Launch Magisk Manager and check SN. Should pass.
Hit the home button.
Clear recent apps.
Open SELMC, and it's back to enforcing.
Change back to permissive.
Hit the home button.
Re-launch MM and check SN, and it comes back CTS fail.
If you stay in MM and wait for a while, occasionally clicking check SN, eventually, it'll pass without changing anything.
If you change tasks over to SELMC, you'll see it's still in permissive as well.
It appears the transition from enforcing to permissive causes SN to fail for a while, and SELMC reverts back to enforcing if cleared from recent tasks, and re-activating it causes SN to fail for a period of time?
Click to expand...
Click to collapse
Sounds like MagiskHide deamon takes a short wile to start up after the change, or something like that. Seems normal to me... If you wan't a more permanent solution than SELMC, try using the script I posted earlier.
Didgeridoohan said:
Sounds like MagiskHide deamon takes a short wile to start up after the change, or something like that. Seems normal to me... If you wan't a more permanent solution than SELMC, try using the script I posted earlier.
Click to expand...
Click to collapse
I gave your script a try, but it didn't work.
I created the file with the same contents/name by copy/paste, and put it in the folder you specified using Root Explorer.
Rebooted the phone, and checked selinux status using "sestatus" and it said enforcing.
Tried manually typing in the commands in your post into terminal emulator...
#!/system/sh (which didn't show a response.)
setenforce 0 (responded "Couldn't set enforcing to 0. Permission denied.")
So I tried...
su
setenforce 0
After that it shows permissive.
Ran SambaDroid, and it works fine, and SN passes.
Suggestions as to what is stopping permissive from applying at boot using your method?
What does #!/system/sh do?
Sorry, I don't know much about Linux, but I'm open to learning.
andrewsfm said:
...
Suggestions as to what is stopping permissive from applying at boot using your method?
What does #!/system/sh do?
Sorry, I don't know much about Linux, but I'm open to learning.
Click to expand...
Click to collapse
https://en.wikipedia.org/wiki/Shebang_(Unix)
MagiskHide sets pseudo-enforcing since Magisk 11 because enforcing is needed to pass SafetyNet
andrewsfm said:
I gave your script a try, but it didn't work.
I created the file with the same contents/name by copy/paste, and put it in the folder you specified using Root Explorer.
Rebooted the phone, and checked selinux status using "sestatus" and it said enforcing.
Tried manually typing in the commands in your post into terminal emulator...
#!/system/sh (which didn't show a response.)
setenforce 0 (responded "Couldn't set enforcing to 0. Permission denied.")
So I tried...
su
setenforce 0
After that it shows permissive.
Ran SambaDroid, and it works fine, and SN passes.
Suggestions as to what is stopping permissive from applying at boot using your method?
What does #!/system/sh do?
Sorry, I don't know much about Linux, but I'm open to learning.
Click to expand...
Click to collapse
Could be that your file doesn't have the proper line endings. What text editor did you use (Notepad doesn't work)?
I'm attaching the file I used. Unzip it and place it in /magisk/.core/post-fs-data.d, reboot and see if that works.
By the way, I just realised I mistyped earlier. Not at all what i had named the file... Fingers going on auto I guess. Updated my earlier post.
Didgeridoohan said:
Could be that your file doesn't have the proper line endings. What text editor did you use (Notepad doesn't work)?
I'm attaching the file I used. Unzip it and place it in /magisk/.core/post-fs-data.d, reboot and see if that works.
By the way, I just realised I mistyped earlier. Not at all what i had named the file... Fingers going on auto I guess. Updated my earlier post.
Click to expand...
Click to collapse
Yeah, I used notepad... Should have used UltraEdit I guess?
Just downloaded your script and installed it, and it works fine now.
SambaDroid worked right off the bat without needing to remember to open SELMC every time before and after.
Thanks!
Didgeridoohan said:
Could be that your file doesn't have the proper line endings. What text editor did you use (Notepad doesn't work)?
I'm attaching the file I used. Unzip it and place it in /magisk/.core/post-fs-data.d, reboot and see if that works.
By the way, I just realised I mistyped earlier. Not at all what i had named the file... Fingers going on auto I guess. Updated my earlier post.
Click to expand...
Click to collapse
Is this a bug in Magisk?
Meowdib said:
Is this a bug in Magisk?
Click to expand...
Click to collapse
No. Why do you think that?
andrewsfm said:
Nevermind my last post... Picked up the phone again, and opened SELinuxModeChanger and found that it had reverted back to enforcing on its own. Changed it to permissive, and then went back to Magisk Manager, and SafetyNet fails until I revert the setting back to enforcing. Seems like it works the first time, and then stops?
Click to expand...
Click to collapse
I have an S7 and a modified stock kernel with SELinux permissive. I enabled Magisk hide and only enabled SystemUI and SafetyNet passed.
Sent from my S7.
andrewsfm said:
Yeah, I used notepad... Should have used UltraEdit I guess?
Just downloaded your script and installed it, and it works fine now.
SambaDroid worked right off the bat without needing to remember to open SELMC every time before and after.
Thanks!
Click to expand...
Click to collapse
Sorry for reviving a somewhat old thread. I was just curious if with this script, do apps that need SELinux Permissive work, AND SafetyNet still passes? Thanks!
jbw716 said:
Sorry for reviving a somewhat old thread. I was just curious if with this script, do apps that need SELinux Permissive work, AND SafetyNet still passes? Thanks!
Click to expand...
Click to collapse
Magisk Hide have a pseudo-enforcing feature that will make SELinux seem enforcing to hidden apps, even though it's permissive. Including SafetyNet.
So the answer to your question is: yes.
I request a thread regarding this issue. The script is very helpfull and i currently dont know any other way making selinux stay permanently on permissive. Many people are having this issue with soundmods like arise which require permissive selinux. Thnaks!!
nadejo said:
I request a thread regarding this issue. The script is very helpfull and i currently dont know any other way making selinux stay permanently on permissive. Many people are having this issue with soundmods like arise which require permissive selinux. Thnaks!!
Click to expand...
Click to collapse
Are you asking for a module to install the necessary script? Like I've provided here https://forum.xda-developers.com/apps/magisk/module-magisk-selinux-permissive-script-t3577549.
AS OF 03/07/2018
Support and development of this module have been discontinued.
A replacement module can be found here : https://forum.xda-developers.com/apps/magisk/module-magisk-selinux-manager-t3760042
This is a very simple module that installs a post-fs-data.sh script which enables SELinux Permissive Mode. This is useful for certain audio mods and removes the need to understand Magisk's file system & boot logic. No need to create your own scripts, just flash and forget.
I have only tested this on my Verizon HTC 10, but this module is so simple and generic that it should work on any Android device with SELinux.
This module has been tested on and is compatible with Magisk v11.6-15.2.
Disclaimer & Recommendations: This module should be used as a last resort only if appropriate SELinux Permissions can not be generated and injected into the SELinux Policy using selinux-inject, supolicy or magiskpolicy. Putting your device into Permissive Mode will essentially disable all of the operating system level security built into Android and allow any app in any context to do whatever it wants. Actions requiring root access will still trigger your SU Manager App, but all apps have elevated privileges due to permissive and may be able to take malicious actions on your device without needing root access. If you find that this module fixes issues you are experiencing with an app I recommend contacting the app developer and trying to work with them to isolate the necessary SELinux Permissions and have them injected into the SELinux Policy at startup.
Here is a discussion of some of concerns to consider when running your device in Permissive Mode : https://forum.xda-developers.com/general/general/discussion-root-selinux-risks-t3607295
Github Repo : https://github.com/Jman420/magisk-permissive-script
Change Log :
v1.0 - Initial Release
v1.1 - Update to Module Template v1400
v1.2 - Update to Module Template v1500
thank you brother!
LeEco LePro 3 Atmos can work finally!
huaiyue said:
thank you brother!
Can you tell me how to install LeEco LePro 3 Atmos ?
I hava supersu systemless.
Click to expand...
Click to collapse
These two things are completely unrelated.
If you want to install something, you install it. There's not much more to that.
huaiyue said:
thank you brother!
Can you tell me how to install LeEco LePro 3 Atmos ?
I hava supersu systemless.
Click to expand...
Click to collapse
In Magisk, go to the Modules section, and select the "+", and select the zip you downloaded.
Jman420 said:
This is a very simple module that installs a post-fs-data.sh script which enables SELinux Permissive Mode. This is useful for certain audio mods and removes the need to understand Magisk's file system & boot logic. No need to create your own scripts, just flash and forget.
I have only tested this on my Verizon HTC 10, but this module is so simple and generic that it should work on any Android device with SELinux.
Github Repo : https://github.com/Jman420/magisk-permissive-script
Click to expand...
Click to collapse
LeEco LePro 3 Atmos can work
however
xposed systemless failed.
---------- Post added at 01:32 ---------- Previous post was at 01:31 ----------
ahrion said:
These two things are completely unrelated.
If you want to install something, you install it. There's not much more to that.
Click to expand...
Click to collapse
http://imgur.com/a/Sbf9p
dolby fc.
---------- Post added at 01:36 ---------- Previous post was at 01:32 ----------
jhedfors said:
In Magisk, go to the Modules section, and select the "+", and select the zip you downloaded.
Click to expand...
Click to collapse
thank you brother!
Thanks a lot
huaiyue said:
thank you brother!
LeEco LePro 3 Atmos can work finally!
Click to expand...
Click to collapse
Regarding your other post mentioning Xposed (which I'm not quoting cause it's a mess). I'm running on Nougat so I can't use Xposed and haven't tested with it. If you give me more details I can try to determine what the issue is. Logs, error messages, symptoms would all be helpful.
Thor™ said:
Thanks a lot
Click to expand...
Click to collapse
I aim to please
I don't understand why this mod is usefull. In the latest version of magisk, there is a semi enforce/permissive linux bypass. The system thinks it's enforced, but in reality is permissive. Or maybe I didn't fully understand it?
its working with s5neo?
I've just flashed this zip. This allows Viper4Android to run in enforcing mode:
https://www.dropbox.com/s/k9cnruw2e1t1d4t/ViPER4Android-supolicy.zip?dl=0
I forgot the source. Maybe Google it
matssa said:
I don't understand why this mod is usefull. In the latest version of magisk, there is a semi enforce/permissive linux bypass. The system thinks it's enforced, but in reality is permissive. Or maybe I didn't fully understand it?
Click to expand...
Click to collapse
I agree that Magisk hides the actual SELinux Mode in such a way that if Magisk Hide is enabled the 'getenforce' command always returns 'Enforcing'. But if you do not run the 'setenforce 0' command the SELinux mode will still be set to 'Enforcing' rather than 'Permissive'. This script puts the SELinux mode into 'Permissive' at startup. Magisk Hide will still hide the fact that you are in Permissive Mode, which I believe is the 'pseudo permissive' mode that Magisk describes. But I can not find any settings or commands within Magisk that enable Permissive Mode.
htr5 said:
I've just flashed this zip. This allows Viper4Android to run in enforcing mode:
https://www.dropbox.com/s/k9cnruw2e1t1d4t/ViPER4Android-supolicy.zip?dl=0
I forgot the source. Maybe Google it
Click to expand...
Click to collapse
It's just a shell script, the source is in the zip file. This is really helpful and is the direction I want to take this project. Permissive Mode is great in that it gets the Apps/Mods that we want to run to work, but I consider it the equivalent of using a sledgehammer to hammer in a finishing nail. I would much rather be able to grant the specific permissions that each App needs rather than enable all permissions for all apps (which is what permissive mode does).
I plan on trying to develop an App which will assist in managing and generating a script which uses 'supolicy' to inject individual SELinux Policy Permissions. I had planned on using the Dolby Atmos LePro3 build as a guinea pig to try to isolate which permissions it needs and put together the supolicy command for them. I've hit a bit of a roadblock in verifying my supolicy command due to the format that the SELinux Policy is stored in on the device. I've found a project called sedump (https://ge0n0sis.github.io/posts/2015/12/exploring-androids-selinux-kernel-policy/) which claims to deserialize the Binary SELinux Policy to a readable format, but I can't seem to get it to work... the process seems to complete, but it generates an empty file... If anyone has experience with SELinux I'd really appreciate any feedback.
cosmin691 said:
its working with s5neo?
Click to expand...
Click to collapse
Dunno, I've only got an HTC 10 for testing. Give it a shot, if it doesn't work just uninstall the Magisk Package. Remember to disable Magisk Hide if you are testing to make sure it actually put your phone into Permissive Mode by using the 'getenforce' command.
It works for oneplus 3t on freedom OS rom.
Jman420 said:
This is a very simple module that installs a post-fs-data.sh script which enables SELinux Permissive Mode. This is useful for certain audio mods and removes the need to understand Magisk's file system & boot logic. No need to create your own scripts, just flash and forget.
I have only tested this on my Verizon HTC 10, but this module is so simple and generic that it should work on any Android device with SELinux.
Github Repo : https://github.com/Jman420/magisk-permissive-script
Click to expand...
Click to collapse
this zip must be flashed using twrp rite ? or stock recovery also will do fine ? because i tried many times to flash recovery for samsung e5 5.1.1 but ended up with boot loop. now running all stock !!
X_GOD said:
this zip must be flashed using twrp rite ? or stock recovery also will do fine ? because i tried many times to flash recovery for samsung e5 5.1.1 but ended up with boot loop. now running all stock !!
Click to expand...
Click to collapse
Should be able to install it through Magisk Manager or TWRP. Let me know if you have problems.
matssa said:
I don't understand why this mod is usefull. In the latest version of magisk, there is a semi enforce/permissive linux bypass. The system thinks it's enforced, but in reality is permissive. Or maybe I didn't fully understand it?
Click to expand...
Click to collapse
Now, I have magisk 11.6 on EMUI marshmallows V4A driver was abnormal because Enforcing selinux. Same happened with SuperSU 2.79. When I changed to permissive mode using terminal emulato/kernerl aduitor init.d script emulator/su.d SuperSU script, V4A driver was normal and it was processing. I like Magisk a lot because of its xposed like modules. Now using jman420's permissive magisk module.
Thor™ said:
Now, I have magisk 11.6 on EMUI marshmallows V4A driver was abnormal because Enforcing selinux. Same happened with SuperSU 2.79. When I changed to permissive mode using terminal emulato/kernerl aduitor init.d script emulator/su.d SuperSU script, V4A driver was normal and it was processing. I like Magisk a lot because of its xposed like modules. Now using jman420's permissive magisk module.
Click to expand...
Click to collapse
Without this module, ARISE is working fine, processing in 48000 on my side, so for V4A I don't think this is necessary, at least on my side.
Sent from my OnePlus3 using XDA Labs
matssa said:
Without this module, ARISE is working fine, processing in 48000 on my side, so for V4A I don't think this is necessary, at least on my side.
Click to expand...
Click to collapse
For ARISE I used to flash permissive script by osm0sis. Otherwise no luck with V4A, AM3D and Dolby.
Thor™ said:
For ARISE I used to flash permissive script by osm0sis. Otherwise no luck with V4A, AM3D and Dolby.
Click to expand...
Click to collapse
Strange... Did you enable magisk hide? If not, that is the reason.
Sent from my OnePlus3 using XDA Labs
matssa said:
Strange... Did you enable magisk hide? If not, that is the reason.
Click to expand...
Click to collapse
No, I was using SuperSU 2.79. Same happened with MagiskSU.
Hello all
viper4android refreshes very rarely and can not keep up with nexus / pixels.
I have seen many guides that suggested deleting the configuration file in /etc/audio_effects.conf.
I think it's a horrible thing! in fact, just insert few strings into another file in /vendor/etc/audio_effects.conf
Under libraries sections:
v4a_fx {
path /system/lib/soundfx/libv4a_fx_ics.so
}
Under effects sections:
v4a_standard_fx {
library v4a_fx
uuid 41d3c987-e6cf-11e3-a88a-11aba5d5c51b
}
it is very important that selinux is set to permissive mode.
Open a Shell :
$ su
# setenforce 0
P.S. install busybox first
MT88 said:
Hello all
viper4android refreshes very rarely and can not keep up with nexus / pixels.
I have seen many guides that suggested deleting the configuration file in /etc/audio_effects.conf.
I think it's a horrible thing! in fact, just insert few strings into another file in /vendor/etc/audio_effects.conf
Under libraries sections:
v4a_fx {
path /system/lib/soundfx/libv4a_fx_ics.so
}
Under effects sections:
v4a_standard_fx {
library v4a_fx
uuid 41d3c987-e6cf-11e3-a88a-11aba5d5c51b
}
it is very important that selinux is set to permissive mode.
Open a Shell :
$ su
# setenforce 0
Click to expand...
Click to collapse
Good guide but that setenforce 0 command doesn't stick after reboot as far as I know. To get it to stick you should use an app that does it or create a .sh file and add the permissive kernel code to it. Can't remember where the file goes though.
DEVILOPS 007 said:
Good guide but that setenforce 0 command doesn't stick after reboot as far as I know. To get it to stick you should use an app that does it or create a .sh file and add the permissive kernel code to it. Can't remember where the file goes though.
Click to expand...
Click to collapse
In viper's app there is an option "disable selinux".
You only have to go permissive with magisk and there's an module for it.
With SuperSU you can stay enforced.
Delete musicfx or audiofx and you're good.
Been trying for days to get viper to work,thanks man.works for me
coremania said:
You only have to go permissive with magisk and there's an module for it.
With SuperSU you can stay enforced.
Delete musicfx or audiofx and you're good.
Click to expand...
Click to collapse
personally I prefer to add two lines of code instead of installing an application that allows another application to work
Right very good guide, but you have to go and live permissive with it. The question is, what's better. If you root anyway ???
coremania said:
Right very good guide, but you have to go and live permissive with it. The question is, what's better. If you root anyway ???
Click to expand...
Click to collapse
this is a problem to be submitted to the viper developer
MT88 said:
personally I prefer to add two lines of code instead of installing an application that allows another application to work
Click to expand...
Click to collapse
Dev,you wouldn't happen to know how to get ATMOS working would you?
I prefer to go permissive as well, besides the fact that I'm always permissive even when I don't have V4A installed.
Also, you don't have to install an app, you just put a permissive script in your init.d(if not using Magisk). For Magisk, you put it in /magisk/.core/service.d/.
I've created my own flashable zips to do this, and since it's Magisk, as long as I don't clean flash, I never have to worry about it. [emoji41]
Sent from my Nexus 6P using Tapatalk
Curiousn00b said:
I prefer to go permissive as well, besides the fact that I'm always permissive even when I don't have V4A installed.
Also, you don't have to install an app, you just put a permissive script in your init.d(if not using Magisk). For Magisk, you put it in /magisk/.core/service.d/.
I've created my own flashable zips to do this, and since it's Magisk, as long as I don't clean flash, I never have to worry about it. [emoji41]
Click to expand...
Click to collapse
here we talk about viper. Magisk and company should be treated elsewhere. Just create an init file for selinux.
Not a Magisk module. If you're using Magisk, you can't stick the init.d script in /system/etc/init.d/ since the system won't being using that location IF you're using Magisk. That's why I included both locations just in case someone that's using Magisk came across the post.
Either way, I was still talking about Viper.
Sent from my Nexus 6P using Tapatalk
I've been using latest Magnum opus on 8.1 without any problems or changes needed to the system. And it works perfectly fine with viper+Dolby config
coremania said:
You only have to go permissive with magisk and there's an module for it.
With SuperSU you can stay enforced.
Delete musicfx or audiofx and you're good.
Click to expand...
Click to collapse
Maybe you can. Have never had ARISE or Viper work without permissive, on either Magisk or SuperSU.
Not maybe, supersu makes it possible to stay enforced with viper and dolby. With magisk Viper might be possible enforced but dolby will run only permissive with magisk.
Tested so many times.
coremania said:
Not maybe, supersu makes it possible to stay enforced with viper and dolby. With magisk Viper might be possible enforced but dolby will run only permissive with magisk.
Tested so many times.
Click to expand...
Click to collapse
Wrong.
snsone said:
Wrong.
Click to expand...
Click to collapse
After every reboot I guess
coremania said:
After every reboot I guess
Click to expand...
Click to collapse
Works after any reboot with enforcing, no need for permissive
Deleted
@snsone are you using android oreo? And if so, how are you doing that?
Hey all,
Android 7.1.1, Magisk 20.4 (on Stable update channel), Magisk Manager is hidden (as "Manager", tried "MM" as well) and the updated Sony app was added to Magisk Hide list.
Data & Cache were cleared for the app as well.
https://play.google.com/store/apps/details?id=com.playstation.remoteplay
But on launch, it crashes with error 88001003, which seems to indicate root detection.
The previous version 3.0 has worked flawlessly on the same system with same settings.
Does anyone know a workaround, could the app now be checking the system for root-compatible apps and block from there ?
Any way to find out how the app detects root?
Any feedback is very welcome.
Full Manager obfuscation capabilities aren't available on Android versions lower than 9. Could be what's causing your issues...
For what it's worth I can start the app just fine on my Android 9 OP3T with Canary build 21004 and hidden Canary Manager 310.
Try uninstalling the Manager and see if that makes a difference.
Log Cat info :
Code:
[10-15 14:29:26.760 4218:4218 D/PRCNT_#RecentsModel#]
#createTaskStack# :: task=PS Remote Play, isTopRunningTask=false, isVisible=false, isLocked=false, isKnoxTask=false, isHideThumbnail=false, isLongLive=false
Didgeridoohan said:
Try uninstalling the Manager and see if that makes a difference.
Click to expand...
Click to collapse
Sadly no difference (and deleted app's data + cache of course). Would you have any other ideas?
Spartacus500 said:
Log Cat info :
Code:
[10-15 14:29:26.760 4218:4218 D/PRCNT_#RecentsModel#]
#createTaskStack# :: task=PS Remote Play, isTopRunningTask=false, isVisible=false, isLocked=false, isKnoxTask=false, isHideThumbnail=false, isLongLive=false
Click to expand...
Click to collapse
Thanks but I'm not sure how it's supposed to help?
Ps24u said:
Sadly no difference (and deleted app's data + cache of course). Would you have any other ideas?
Click to expand...
Click to collapse
Many things may trigger detection, not only Magisk:
https://www.didgeridoohan.com/magisk/MagiskHide#hn_Hiding_root_from_apps
Thanks Didgeridoohan, after many hours I found 2 culprits that triggered root detection on my system.
For the Sony Remote Play app mentionned in this thread: SELinux set to permissive was the culprit.
After disabling the Magisk module for SElinux, the app runs normally, no crash, all good.
But it's pretty annyoing having to reboot to enable/disable SELinux just to run this app.
Would you know if there's a way to either toggle SElinux in realtime while the os is running or to have the Sony app always believe SElinux is set to enforcing ?
For the second app, it was dumb, it looked for "twrp" folder on internal storage. After I renamed the folder, the app launches and runs perfectly.
But again it's far from ideal to do it manually all the time. So for this case also, is there a way to hide the "twrp" folder from this app, either via magisk module, script or otherwise?
Thanks a lot for your tips and awesome site, probably the best ressource for all things Magisk. :bow:
Ps24u said:
Would you know if there's a way to either toggle SElinux in realtime while the os is running or to have the Sony app always believe SElinux is set to enforcing ?
Click to expand...
Click to collapse
That's just a simple terminal command (which is exactly what the module uses and runs at boot). You can run that whenever and it'll change selinux to the state you want on the fly, no need for a reboot.
Permissive:
Code:
setenforce 0
Enforcing:
Code:
setenforce 1
Needs to be run as su, of course (you could add "su -c" in front of the command to make it easy).
You could either set up a script with an app like Tasker or use an app that's made for toggling selinux (if you look around there should be a few available).
For the second app, it was dumb, it looked for "twrp" folder on internal storage. After I renamed the folder, the app launches and runs perfectly.
But again it's far from ideal to do it manually all the time. So for this case also, is there a way to hide the "twrp" folder from this app, either via magisk module, script or otherwise?
Click to expand...
Click to collapse
To hide the TWRP directory you could use an isolation app to stop the app from detecting what you have on your device. When it comes up the internal storage, Storage isolation is the most powerful.
Another option could be to set up a Tasker task (or similar) that renames the folder and then launches the app. Another Tasker profile could then keep track of when the app is running and rename the folder again once it's closed. Or it might be more reliable to run a task manually when you're done with the app. I'm just mentioning this to show some options. It's nowhere near as elegant as using an isolation app...
Thanks a lot for your tips and awesome site, probably the best ressource for all things Magisk. :bow:
Click to expand...
Click to collapse
No worries, I'm glad you found it useful and could get things figured out.
Didgeridoohan said:
That's just a simple terminal command (which is exactly what the module uses and runs at boot). You can run that whenever and it'll change selinux to the state you want on the fly, no need for a reboot.
Permissive:
Code:
setenforce 0
Enforcing:
Code:
setenforce 1
Needs to be run as su, of course (you could add "su -c" in front of the command to make it easy).
You could either set up a script with an app like Tasker or use an app that's made for toggling selinux (if you look around there should be a few available).
Click to expand...
Click to collapse
That strangely doesn't do the trick. If SElinux is set to permissive at boot via Magisk module, toggling to Enforcing afterwards doesn't allow the app to launch (crashes with same error 88001003, even after deleting data+cache).
It seems the app somehow knows if SElinux was set to permissive on boot and doesn't care if SElinux is switched to Enforcing afterwards.
Due to how my setup works I need Permissive at boot (mount cifs folders) so I'm in pinch.
I use selinux_permissive_v2.zip on Magisk 20.4.
I also tried to set SElinux to permissive via a script in /data/adb/service.d
Code:
#!/system/bin/sh
setenforce 0
But same results, toggling to Enforcing afterwards doesn't allow the app to launch.
I tried toggling with "su -c setenforce 1" in Termux, and with SELinux Toggler.
However, If the phone boots with Enforcing, and then I toggle to Permissive after boot and then back to Enforcing, the app launches without issues, strange!
There is a mystery going on here...
Didgeridoohan said:
To hide the TWRP directory you could use an isolation app to stop the app from detecting what you have on your device. When it comes up the internal storage, Storage isolation is the most powerful.
Click to expand...
Click to collapse
That worked straight away, awesome!
On my Samsung Galaxy S7 edge Custom Pie 9.0 Rom NFE root Magisk, this application does not work, keeps saying "something went wrong", I changed the twrp folder to aaaTWRPaaa but still the application won't work. I also changed selinux mode changer to permisive, but after this change also doesn't work, my antivirus screams selinux permisive is dangerous. Any ideas ?
Spartacus500 said:
On my Samsung Galaxy S7 edge Custom Pie 9.0 Rom NFE root Magisk, this application does not work, keeps saying "something went wrong", I changed the twrp folder to aaaTWRPaaa but still the application won't work. I also changed selinux mode changer to permisive, but after this change also doesn't work, my antivirus screams selinux permisive is dangerous. Any ideas ?
Click to expand...
Click to collapse
From my testing, PS Remote Play doesn't care about TWRP folder.
Spartacus, for now try to boot with SElinux to Enforced, and clear data/cache for the app.
I hope Didgeridoohan can help solve the SElinux pemissive at boot mystery.
Ps24u said:
I hope Didgeridoohan can help solve the SElinux pemissive at boot mystery.
Click to expand...
Click to collapse
Not really... I've no idea why the app would behave like that.
But I have a thought: how do you set up your cifs folders mounting? With a script? If so, could you temporarily set SELinux permissive only during that time? If you're lucky, it might be that's enough... I have no idea how cifs folder mounting works, so I'm just throwing ideas aimed at your head.
Ps24u said:
From my testing, PS Remote Play doesn't care about TWRP folder.
Spartacus, for now try to boot with SElinux to Enforced, and clear data/cache for the app.
I hope Didgeridoohan can help solve the SElinux pemissive at boot mystery.
Click to expand...
Click to collapse
I did as you said, deleted the TWRP folder from internal storage, also deleted the Titanium backup folder, no result, Selinux I have enforcing, the application still shows an error on startup
I also have a question, is your audit error the same as mine? Maybe there is a bug here
audit (error)
Code:
type=1400 audit(1603135249.830:2343): avc: denied { read } for pid=7381 comm="zCloudWorkerThr" name="enforce" dev="selinuxfs" ino=4 scontext=u:r:untrusted_app:s0:c212,c259,c512,c768 tcontext=u:object_r:selinuxfs:s0 tclass=file permissive=1 SEPF_SM-N935F_9_0001 audit_filtered
Code:
type=1400 audit(1603135249.830:2344): avc: denied { open } for pid=7381 comm="zCloudWorkerThr" path="/sys/fs/selinux/enforce" dev="selinuxfs" ino=4 scontext=u:r:untrusted_app:s0:c212,c259,c512,c768 tcontext=u:object_r:selinuxfs:s0 tclass=file permissive=1 SEPF_SM-N935F_9_0001 audit_filtered
Didgeridoohan said:
Not really... I've no idea why the app would behave like that.
But I have a thought: how do you set up your cifs folders mounting? With a script? If so, could you temporarily set SELinux permissive only during that time? If you're lucky, it might be that's enough... I have no idea how cifs folder mounting works, so I'm just throwing ideas aimed at your head.
Click to expand...
Click to collapse
In the context of Cifs, I need SELinux permissive during actual use, not only during the mounting phase, so it cannot be done unfortunately.
Spartacus500 said:
I did as you said, deleted the TWRP folder from internal storage, also deleted the Titanium backup folder, no result, Selinux I have enforcing, the application still shows an error on startup
I also have a question, is your audit error the same as mine? Maybe there is a bug here
audit (error)
Click to expand...
Click to collapse
I'm not sure what / how to "audit" ?
I'm back again, Samsung Galaxy S7 edge Custom Pie 9.0 Rom. Selinux enforcing, PS Remote Play 4.0.0 keeps crashing, I uninstalled Magisk root and PS Remote Play 4.0.0 app works fine on my S7, I reload Magisk root via TWRP and PS Remote Play 4.0.0 shows error again ...
You've added PS Remote Play to the "Magisk Hide" list already, right ?
If not, add it, then clear data/cache or Uninstall and reinstall the app but don't launch it, and reboot.
Ps24u said:
You've added PS Remote Play to the "Magisk Hide" list already, right ?
If not, add it, then clear data/cache or Uninstall and reinstall the app but don't launch it, and reboot.
Click to expand...
Click to collapse
Of course, right after installing Magisk I hid hide root for PS Remote Play 4.0.0 and also changed the name of Magisk manager to something else, cleaning the memory for this application does not help either, every time I open the application it says "something went wrong" and error code ... All I need to do is remove the Magisk root and the app works. I'm using Magisk 20400, tested 21000 and Canary 21005 version and on neither of these versions this app shows the same error
Sorry I can't help more. I'm on Magisk 20.4 and M.Manager 7.5.1, also on Android 7.1.1 official Sony rom.
I performed the test, removed the Magisk root, PS Remote Play 4.0.0 works, when I install only Magisk manager, then PS REMOTE PLAY 4.0.0 detects Magisk and shows an error, after removing Magisk manager, PS Remote Play 4.0.0 works again, but it's enough that I will upload root Magisk, hide root hide, remove Magisk manager then PS Remote Play 4.0.0 shows error ...
I've got the same issue, anyone find a workaround?
Same here. This app work in the past, now it doesnt open. I dont know why Sony now dont left we use it because of root. It thinks that we will hack something. Mas, if Sony continues to do this and **** the past generation with last updates I will left consoles for while.
Im using Android 8.1