FORUMS
Remove All Ads from XDA

Apps that modify SELinux state are now forbidden on Google Play.

571 posts
Thanks Meter: 1,524
 
By MrBIMC, Senior Member on 31st March 2015, 10:43 AM
Post Reply Email Thread
From this day onwards, apps that Change state of SELinux are forbidden on Google Play Store. Those, who have such apps, have 14 days to fix violations or their apps will be removed.

Here's example of message from google:

This is a notification that your application, SELinux Mode Changer, with package ID com.mrbimc.selinux, is currently in violation of our developer terms.


REASON FOR WARNING: Violation of the dangerous products provision of the Content Policy:

“Don’t transmit or link to… items that may introduce security vulnerabilities to or harm user devices, apps, or personal data.”
After a regular review, we have determined that your app lowers a user’s device security by modifying or disabling SELinux on the device. To ensure a safe user experience for Play users, we have determined that apps with this functionality are noncompliant.

Please remove this functionality from your app within 14 days to achieve policy compliance. Once approved, your application will again be available with all installs, ratings and reviews intact.

This notification also serves as notice for other apps in your catalog. You can avoid further administrative action by immediately ensuring that no other apps in your catalog are in violation of (but not limited to) the above policy. Please also ensure your apps’ compliance with the Developer Distribution Agreement and Content Policy.

All violations are tracked. Additional suspensions of any nature may result in the termination of your developer account, and investigation and possible termination of related Google accounts. If your account is terminated, payments will cease and Google may recover the proceeds of any past sales and/or the cost of any associated fees (such as chargebacks and transaction fees) from you.

If you feel we have made this determination in error -or feel that this functionality has been misinterpreted, please submit an appeal to the Google Play policy team through this Google Play Help Center article.

The Google Play Team


New definition of "dangerous product
Google play content policy
Google play distribution agreement

What are we going to do?
The Following 6 Users Say Thank You to MrBIMC For This Useful Post: [ View ] Gift MrBIMC Ad-Free
 
 
31st March 2015, 10:53 AM |#2  
Junior Member
Thanks Meter: 12
 
More
Exclamation
I can confirm this issue as I also received this message by Google-Play some hours ago.

My app is using "setenforce 0" to allow the "mediaserver"-process loading an .SO-file from the /data-partition.
The loaded .SO-file is then using some C-commands to modify the internal audio-routings of the device.

As hereby the "mediaserver"-process is executing the by SELinux blocked commands and not the initial commands executed via "su", the modification by SuperSU doesn't take affect here ("SU-commands are always permissive").


What's the workaround? Modifying/scrambling the "setenforce 0" to not get scanned by Google's bots?
The Following User Says Thank You to funtax For This Useful Post: [ View ] Gift funtax Ad-Free
31st March 2015, 08:12 PM |#3  
Senior Member
Thanks Meter: 436
 
Donate to Me
More
Quote:
Originally Posted by funtax

I can confirm this issue as I also received this message by Google-Play some hours ago.

My app is using "setenforce 0" to allow the "mediaserver"-process loading an .SO-file from the /data-partition.
The loaded .SO-file is then using some C-commands to modify the internal audio-routings of the device.

As hereby the "mediaserver"-process is executing the by SELinux blocked commands and not the initial commands executed via "su", the modification by SuperSU doesn't take affect here ("SU-commands are always permissive").


What's the workaround? Modifying/scrambling the "setenforce 0" to not get scanned by Google's bots?

Same here. Got 4 emails from Google for same violation. Not exactly if I can bypass this problem by using superSU properly.
31st March 2015, 08:58 PM |#4  
Member
Thanks Meter: 53
 
More
Quote:
Originally Posted by jerryfan2000

Same here. Got 4 emails from Google for same violation. Not exactly if I can bypass this problem by using superSU properly.

Might I ask you which apps and features are affected?
31st March 2015, 09:02 PM |#5  
Senior Member
Thanks Meter: 436
 
Donate to Me
More
Quote:
Originally Posted by PhinxApps

Might I ask you which apps and features are affected?

Button Savior (root). Assistive Zoom, oneClick Scroll. In my app, I create a jar with private API invocation in it and start the jar as a shell command by exec or something that I dont quit remember.
The Following User Says Thank You to jerryfan2000 For This Useful Post: [ View ] Gift jerryfan2000 Ad-Free
1st April 2015, 05:58 AM |#6  
Senior Member
Thanks Meter: 351
 
Donate to Me
More
I got the same note, too. Oddly, two selinux mode changer apps are still in Play. Maybe they're less worried about apps that say in the title that they turn off selinux. Or maybe they just haven't got to them?
1st April 2015, 08:36 AM |#7  
Junior Member
Thanks Meter: 12
 
More
Quote:
Originally Posted by arpruss

I got the same note, too. Oddly, two selinux mode changer apps are still in Play. Maybe they're less worried about apps that say in the title that they turn off selinux. Or maybe they just haven't got to them?

Hmm, the e-mail is just a warning.. I think the apps will be removed in 13 days.
The title shouldn't matter, I assume it's just a scanner/grep which they run against eg. the classes.dex and search for "setenforce".

My app doesn't use this command normally, nor is it an app which is used by the 0815-user - it cannot be a human who decides about good/bad

But does this help us in any way?
1st April 2015, 08:43 AM |#8  
Senior Member
Thanks Meter: 65
 
More
This zip is just as good if not better. Only problem is is I don't think there's a way to go back and forth between permissive and enforcing. I did not make this trip, I'm not a programmer, and I'm taking no credit for it. I just found it awhile ago and decided to hold onto it.. Going to recovery, flash the zip, presto.

https://mega.co.nz/#!jhgA3Spb!oOS9ru...bNk1iyrLrq-lus
The Following User Says Thank You to tmjm28 For This Useful Post: [ View ] Gift tmjm28 Ad-Free
1st April 2015, 08:47 AM |#9  
Junior Member
Thanks Meter: 12
 
More
Quote:
Originally Posted by tmjm28

This zip is just as good if not better. Only problem is is I don't think there's a way to go back and forth between permissive and enforcing. I did not make this trip, I'm not a programmer, and I'm taking no credit for it. I just found it awhile ago and decided to hold onto it.. Going to recovery, flash the zip, presto.

https://mega.co.nz/#!jhgA3Spb!oOS9ru...bNk1iyrLrq-lus

Thanks for sharing!

I fear we cannot tell our (sometimes quite stupid) users "flash a permissive kernel" if it's "in theory" simple to temporary make SELinux permissive by a single command.
The Following User Says Thank You to funtax For This Useful Post: [ View ] Gift funtax Ad-Free
1st April 2015, 06:36 PM |#10  
Chainfire's Avatar
Senior Moderator / Senior Recognized Developer - Where is my shirt?
Thanks Meter: 83,986
 
Donate to Me
More
Quote:
Originally Posted by funtax

Thanks for sharing!

I fear we cannot tell our (sometimes quite stupid) users "flash a permissive kernel" if it's "in theory" simple to temporary make SELinux permissive by a single command.

... which isn't possible on bootloader locked (exploit freed) devices
2nd April 2015, 12:29 PM |#11  
Junior Member
Thanks Meter: 12
 
More
Question
Has anyone an idea how to exactly interprete this message from Google?

I assume they parse the APK for "setenforce" and blame all apps which use it.
I fully understand and confirm Google's decision, no matter that it's realy a pain in the a** for some of us.

So, what are your thoughts about the following:

1. use a crypted version of "setenforce 0" which hopefully bypasses Google's scanners
2. do the modifications you need to do and hope this modifications are still working after enforced-mode is active again (how would a "execmod"-exception perform if the text-relocations have been made while SELinux was off?)
3. now call setenforce again but with "1", to re-renable SELinux

In other words:

1. would SELinux recognize that a text-relocation was made while it was disabled and then activated?
2. would it be ok to temporary disable SELinux but then re-enable it shortly after the required modifications?

@Chainfire: maybe #1 is something you might know due to SuperSU?
Post Reply Subscribe to Thread

Tags
content violation, google play, selinux, setenforce

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

Advanced Search
Display Modes