• Introducing XDA Computing: Discussion zones for Hardware, Software, and more!    Check it out!

[Discussion] Root & SELinux Risks

Search This thread

Jman420

Senior Member
Jul 21, 2014
183
307
There have been a bunch of discussions around SELinux Permissive mode recently in the Audio Mod & Kernel circles. I'd like to start a discussion here around the risks associated with Root and SELinux. I've done some research already (as of 5/15/2017) and will include my notes and conclusions below, but they may be subject to change as new information comes up.

The main question I wanted to answer is this:
Is being Rooted essentially the same as being in Permissive mode?

Background:
Security is always more secure in serialized layers; meaning that each layer has to be passed through one after the other. Unix provides its standard permissions as a single layer of security (for the security buffs out there this is a Discretionary Access Control system). SELinux adds an additional layer of security on top of the standard Unix Permissions by providing a Mandatory Access Control system through the enforcement of a global permissions policy. The main purpose of SELinux is to prevent escalation of privilege attacks, for example to prevent an MMS app from modifying Network Settings or accessing other resources not related to MMS. So SELinux essentially confines all apps (system or otherwise) to a realm of legitimate activity.

The SELinux Policy is actually a 'compiled' (more serialized than compiled, but it's referred to as compiled) version of a human-readable text version of the permissions contained in the policy. On a Stock Unrooted device the SELinux Policy is distributed with the ROM and is never modified except for during ROM upgrades if necessary. This provides the highest level of security (assuming the ROM provides a tight policy) since the SELinux Policy should only contain permissions for legitimate activities according to the device manufacturer and/or carrier. So SELinux would, in theory, restrict any malicious app to safe activities, preventing serious harm to your device & data.

Since the SELinux Policy restricts full access to the device in order to achieve root some of those restrictions need to be bypassed. How this is performed varies, but the end goal is the same : inject new permissions into the SELinux Policy to allow the root implementation full access to the device. If the root implementation is ethical then it should only inject permissions related to providing root access. Since root apps will likely require permissions not included in a device's Stock SELinux Policy most root implementations provide tools for injecting permissions into the SELinux Policy at runtime (selinux-inject, supolicy & magiskpolicy). Most root implementations also provide locations for startup scripts which are executed in a root context. These tools and scripts are used legitimately by the root implementation to maintain root access and by root apps to maintain stable functionality.

SELinux provides three modes : Enforcing, Permissive & Disabled (not covered in this discussion). In Enforcing mode SELinux will deny and log any requests for permissions against the SELinux Policy. Enforcing mode is meant for production devices (or devices for end users). In Permissive mode SELinux will only log the requests against the SELinux Policy, but will not deny any requests. Permissive mode is meant for development devices so that developers can isolate the appropriate permissions to include in the SELinux Policy before enabling Enforcing mode and shipping the device for production. While in Permissive mode the logs still capture whether a request would be allowed or denied and can be accessed through the 'dmesg' command by filtering for lines with 'avc' in them.

Possible Attack Vectors:
For a Stock device in Enforcing mode the main attack vector would be SELinux itself and the Unix standard permissions since those are the mechanisms on the device which can allow or deny full device control. This would likely require a very high degree of sophistication and social engineering since the malicious app would essentially be installing a root implementation for it to use to bypass SELinux.

For Rooted devices in Enforcing mode the main attack vectors are the root implementation and/or the user. In theory a malicious app would need to convince the user to grant it root access. From there the malicious app can utilize the tools and script locations provided by the root implementation to inject the permissions it needs for full device control. If the root implementation can be exploited directly then the malicious app may not need the user to grant root access. Another alternate attack vector could be other vulnerable apps, such as startup script compatibility apps. These apps usually require root access so the scripts are run at startup in a root context, but there is no guarantee that the location the startup scripts are placed for that app requires root access to add scripts. So a malicious app could add a script to that location and have its malicious code/permissions executed that way.

For Rooted devices in Permissive mode the main attack vectors are still the root implementation and/or the user. Except that in this situation the malicious app would never need to inject any permissions into the SELinux Policy. Instead it would only need to be granted root access to achieve full device control. The alternate attack vector also still applies.

Quick Summary (or TL;DR):
- Stock & Enforcing --> high level of security; main attack vector is SELinux implementation itself to bypass privilege escalation protection
- Rooted & Enforcing --> moderate level of security; SELinux has already been compromised, main attack vector is root implementation and/or the user in order to acquire root access for full device control, once root access is acquired inject policy permissions for full device control
- Rooted & Permissive --> low level of security; SELinux is only logging the policy requests and won't deny anything, main attack vector is root implementation and/or the user in order to acquire root access for full device control
- Stock & Permissive --> Unsure... ?

Conclusion:
Root is a responsibility and opens you to exploits and vulnerabilities which are handled with compensating controls on Stock devices. My current opinion is that running Root & Enforcing is not the same as running Root & Permissive, but it is very close since the gatekeeper to full device control becomes the root implementation & manager. An attacker needs a higher level of sophistication to interact with the appropriate tools and inject the necessary permissions. But it also shifts more responsibility onto the user since it is up to the user which apps they install and which are granted root access. Root & Enforcing mode provides protection from system attacks (such as MMS attempting to modify Network Settings) and reasonable app security provided that the user restricts root access to legitimate apps & keeps an eye on security.

Sources:
- https://source.android.com/security/selinux/
- https://android.stackexchange.com/q...elinux-is-in-permissive-mode-what-should-i-be
- https://su.chainfire.eu/#selinux-policies-supolicy
- Magisk Scripts : https://forum.xda-developers.com/showpost.php?p=68967705&postcount=2
- SuperSu Scripts : https://su.chainfire.eu/#updates-sud
 
@Jman420, the answer to your main question is NO.

Basically, obtaining Root only allows you the ability to modify the system.

SELinux is a completely different entity. To change a devices SELinux State is written into the devices Kernel. The kernel is a part of the ROM. It determines whether or not the device is permitted to change it's SELinux State.

It's really challenging to explain via text..


"Live Long and Prosper..."
~Ambassador S'chn T'gai Spock

Sent via Communicator [D2VZW] from the Bridge of the U.S.S. Enterprise
 

Jman420

Senior Member
Jul 21, 2014
183
307
@Jman420, the answer to your main question is NO.

Basically, obtaining Root only allows you the ability to modify the system.

SELinux is a completely different entity. To change a devices SELinux State is written into the devices Kernel. The kernel is a part of the ROM. It determines whether or not the device is permitted to change it's SELinux State.

It's really challenging to explain via text..


"Live Long and Prosper..."
~Ambassador S'chn T'gai Spock

Sent via Communicator [D2VZW] from the Bridge of the U.S.S. Enterprise

I think we both came to the same conclusion : Running Root & Enforcing is not the same as Root & Permissive, it still offers protection from less sophisticated attacks.

But I don't think everything in your post is entirely true though. Yes, Root access allows you to modify system (and some other directories). But as I explained in order to achieve Root the SELinux Policy usually needs to be modified and the root implementations provide tools for modifying the SELinux Policy. In the cases I've seen (magisksu & supersu) an app or script needs to be Root in order to access those tools. So being Rooted and modifying the SELinux Policy are related. Root and SELinux are two different things, but they are related due to having to bypass SELinux protections to achieve Root.

Yes, the kernel actually determines which SELinux modes are supported for your device and the kernel is normally installed with a ROM. But after Rooting you can install custom kernels without installing a ROM. I believe there are a few devices in which this is the only way to get the device into Permissive mode.
 
@Jman420, you do have the gist of this... But I I'll try my best to explain it a bit more... User Friendly :)

Apart from a typical kernel modification, the actual SELinux (Security-Enhanced Linux) tools/policies are all located in one file "/sepolicy". That file, simply, contains the instructions for the actual control mechanisms typically located in the "/sys/fs/selinux/" directory.

Obtaining/Gaining proper Root within the device doesn't mean that your granted Root control in one of the devices features within the, commonly referred to as, MAC (Mandatory Access Control) system.

Individuals often confuse the devices Root access with certain, higher privileged roles, that are assigned to the devices Security-Enhanced Linux. The individual with a Rooted device typically confuses the two separate device privileges and should keep in mind that an Android does have multiple device privileges.

But that does mean that restricting root access to a folder means that some additional countermeasures need to be implemented. It just means that those separate policies are typically determined by way of the devices "Kernel" that outlines the users ability to make modifications to the devices "Security-Enhanced Linux" (aka SELinux).

The following URL does explain this in a great way:

Security-Enhanced Linux in Android

Though, you should keep in mind, that the above URL is a start but, if you do a little searching on the Internet, you should be able to locate other websites that explains the SELinux (Security-Enhanced Linux) in different ways that may be in more of a "layman's terms" that is better understood for some non-technical or less-technical minds.


"Live Long and Prosper..."
~Ambassador S'chn T'gai Spock

Sent via Communicator [D2VZW] from the Bridge of the U.S.S. Enterprise
 
  • Like
Reactions: phaino00

Krzysieq

Senior Member
Mar 21, 2017
82
8
Kraków
I know this is an old thread, but the question came to me after I installed a custom rom on my device. I was using AospExtended based on Nougat up to yesterday, now I installed a build based on Oreo. The prior versions I was using were always running in SELinux enforcing mode, which suits me because I don't really want to root my device or compromise it's security in any way (as if installing a custom ROM wasn't compromising it enough already). To my surprise, the latest ROM I flashed runs in SELinux permissive, but I installed the first off the bat application to check for root, and my device is reported as not rooted. But it still runs permissive, so I'm confused. What does that mean for me? The way I understand this discussion, having root and SELinux restrictive would still confine root access to some constraints, whereas with SELinux permissive, a malicious piece of software could theoretically do whatever it pleases. Correct?
 
  • Like
Reactions: Kiruasan

Jman420

Senior Member
Jul 21, 2014
183
307
I know this is an old thread, but the question came to me after I installed a custom rom on my device. I was using AospExtended based on Nougat up to yesterday, now I installed a build based on Oreo. The prior versions I was using were always running in SELinux enforcing mode, which suits me because I don't really want to root my device or compromise it's security in any way (as if installing a custom ROM wasn't compromising it enough already). To my surprise, the latest ROM I flashed runs in SELinux permissive, but I installed the first off the bat application to check for root, and my device is reported as not rooted. But it still runs permissive, so I'm confused. What does that mean for me? The way I understand this discussion, having root and SELinux restrictive would still confine root access to some constraints, whereas with SELinux permissive, a malicious piece of software could theoretically do whatever it pleases. Correct?

Ah, so someone finally falls into the 'Stock & Permissive' category that I didn't cover in the OP.

First, to answer your easy question... Correct, having SELinux enforcing with root would require a malicious app to first obtain root access and then inject necessary SELinux permissions to obtain full device control (or whatever parts it wanted). With SELinux permissive and root the malicious app would probably only need to obtain root access for full device control (and possibly not even that, depending on what it wants to do).

Now... for your SELinux permissive without root situation... to be honest I'm not really sure... You are definitely at higher risk than someone with SELinux enforcing without root, but there (in theory) isn't an SELinux context to serve root access. To obtain full device control a malicious app would need to root your device, which may not be very difficult considering that SELinux is not enforcing any permissions. For partial control... a malicious app may not need to do much of anything other than be installed, again because SELinux isn't enforcing anything. I think in this context it would really depend on what the malicious app is trying to do... if it is stuff that an app can normally do, but it hasn't asked for the permissions then it may be still able to that stuff. But if its an activity that requires root access it would still fail since no root app or context exists. (Need to point out that all of this is just theory... I haven't done any real research or put hard thought into this scenario.)
 
  • Like
Reactions: Krzysieq

Krzysieq

Senior Member
Mar 21, 2017
82
8
Kraków
I'm happy to be the first to fall into that hole ;) although I'm pretty sure I'm not the only person using this particular ROM as it currently is. I know the dev is working hard to clear up the policy so that he can turn SELinux back into enforcing, but he probably still has a way to go. Till that happens I'm probably not going to install any sensitive stuff on my phone just as a precaution. It would be really interesting to hear some expert opinions on the matter. Or maybe - in the spirit of true science - there's an experiment I could conduct on my phone to see how compromised it's security is?
 

Jman420

Senior Member
Jul 21, 2014
183
307
I'm happy to be the first to fall into that hole ;) although I'm pretty sure I'm not the only person using this particular ROM as it currently is. I know the dev is working hard to clear up the policy so that he can turn SELinux back into enforcing, but he probably still has a way to go. Till that happens I'm probably not going to install any sensitive stuff on my phone just as a precaution. It would be really interesting to hear some expert opinions on the matter. Or maybe - in the spirit of true science - there's an experiment I could conduct on my phone to see how compromised it's security is?

Indeed, I agree. Although I am a security professional, I would hardly consider myself a Linux or SELinux expert. I'm sure there are experiments that can be run to determine the level of exposure that Stock Permissive would give... but none that I know of off-hand. Unfortunately I am incredibly busy at work for the next couple of months and likely won't have time to research or investigate.
 
  • Like
Reactions: Kiruasan

Krzysieq

Senior Member
Mar 21, 2017
82
8
Kraków
Perhaps this is slightly off topic, but only just... Does anyone know what is the current problem behind getting custom roms based on Oreo to use SELinux in restrictive mode? I have Xiaomi Mi Max, my Mrs has a Mi 6, and for neither of these does an Oreo-based ROM exist with SELinux in restrictive mode.
 
Perhaps this is slightly off topic, but only just... Does anyone know what is the current problem behind getting custom roms based on Oreo to use SELinux in restrictive mode? I have Xiaomi Mi Max, my Mrs has a Mi 6, and for neither of these does an Oreo-based ROM exist with SELinux in restrictive mode.
I understand your question but, the "restrictive" mode your referring to is called "Enforcing" Mode that is the default SELinux State for all Custom Firmwares.

There's only 2 options for a devices "SELinux State"... "Permissive Mode" and "Enforcing Mode".

By default, a device will be restricted to Enforcing Mode and can only be changed by using a Custom Kernel and, in some Custom Firmwares, this is inclusive.

I hope that I had explained this and answered your question okay via text... :)


~~~~~~~~~~~~~~~
I DO NOT provide support via PM unless asked/requested by myself. PLEASE keep it in the threads where everyone can share.
 
  • Like
Reactions: Krzysieq

Jman420

Senior Member
Jul 21, 2014
183
307
Perhaps this is slightly off topic, but only just... Does anyone know what is the current problem behind getting custom roms based on Oreo to use SELinux in restrictive mode? I have Xiaomi Mi Max, my Mrs has a Mi 6, and for neither of these does an Oreo-based ROM exist with SELinux in restrictive mode.

I've seen some other questions related to this. Unfortunately I don't have an Oreo compatible device right now, so I haven't done any investigation into it. If memory serves the SELinux Enforcing mode is set by a config value at compile time, but for some reason there have been reports that setting that flag in Oreo causes boot issues.

If I had to guess I would say that more likely than not the custom ROM has been modified in such a way that it is violating the SELinux Policy that is being enforced, which is causing a fatal error on boot. But that's just me speculating based on the tiny amount of information I have regarding the issue.

Not really a discussion for this thread though... and I can't provide much help since I don't have an Oreo device.
 
  • Like
Reactions: Krzysieq

Anubhav997

Member
Oct 20, 2012
28
6
Delhi
So from what I understand. Say you are rooted + enforcing or rooted + permissive. It won't matter much cause once someone has gained root access getting around enforcing linux is just a matter of changing the required selinux policies which he/she can easily do given they have root.

So if I am rooted enforcing will just give me some extra "buffer" in terms of security. Right?
 

Jman420

Senior Member
Jul 21, 2014
183
307
So from what I understand. Say you are rooted + enforcing or rooted + permissive. It won't matter much cause once someone has gained root access getting around enforcing linux is just a matter of changing the required selinux policies which he/she can easily do given they have root.

So if I am rooted enforcing will just give me some extra "buffer" in terms of security. Right?

Even when rooted I would recommend having SELinux set to Enforcing. The tools needed to modify the selinux policy will be present on the device, but hopefully be appropriately protected so that only root apps can access them. If you set SELinux to Permissive while rooted then any apps can likely access the tools to modify selinux policy; not that they need to, but would be a good idea in order to ensure persisted infection.

So TL;DR - Yes, rooted + enforcing raises the sophistication needed to execute a successful attack by needing to convince the User to grant the malicious app root access. How much sophistication is needed is likely up for debate... and different for different users...
 
  • Like
Reactions: Anubhav997

FivEawE

Senior Member
Oct 3, 2015
54
21
Hello. I have been wondering how permissive SELinux can be exploited. A lot of custom ROMs are shipping like that, and I would like to switch to one of them since the stock one sucks. If I don't use apps outside of Play store (even then only a couple of them like Messenger) and I only need Magisk for ad blocking, am I really at risk? I am mostly worried about keyloggers and data theft. Thanks.
 

Jman420

Senior Member
Jul 21, 2014
183
307
Hello. I have been wondering how permissive SELinux can be exploited. A lot of custom ROMs are shipping like that, and I would like to switch to one of them since the stock one sucks. If I don't use apps outside of Play store (even then only a couple of them like Messenger) and I only need Magisk for ad blocking, am I really at risk? I am mostly worried about keyloggers and data theft. Thanks.

It all really depends on you and your usage habits. SELinux prevents Apps from accessing portions of the system which it has not explicitly described as part of its normal function. Using Apps that come from the Play Store will help combat some of the risk of disabling SELinux, but you are still at risk of those legitimate Apps being exploited in some way (ie. a website you visit with your Browser App is able to identify that you are on a mobile device and sends malicious packets which exploit the Browser to have it take actions which you have not approved, or an SMS app is exploited in a similar way).

Although the cyber criminals are becoming more and more sophisticated in their attacks, it is still a cost vs reward game that they play. If you are a usual, run-of-the-mill, non-executive or government person then the chances of SELinux attacks being used against you is pretty slim... but your value to criminals can change overnight, so I try to keep myself prepared for any situation.
 
  • Like
Reactions: FivEawE

Jman420

Senior Member
Jul 21, 2014
183
307
Hello. I have been wondering how permissive SELinux can be exploited. A lot of custom ROMs are shipping like that, and I would like to switch to one of them since the stock one sucks. If I don't use apps outside of Play store (even then only a couple of them like Messenger) and I only need Magisk for ad blocking, am I really at risk? I am mostly worried about keyloggers and data theft. Thanks.

I was just thinking about this a bit more and another point which may not be obvious came to mind.

Using official apps from the Play Store while having SELinux disabled could give a false sense of security. I believe that SELinux is a requirement for official ROMs approved by Google. Since the expectation is that SELinux will be enforcing on any devices running Play Store Apps any vulnerabilities which are fixed by SELinux will probably be ignored during development and review processes. Which means that you could be exposing yourself to exploitation even if you use only official apps...

So I may have overstated when I said that using Apps from the Play Store would reduce risk of exploitation... Really the best advice I can give is to keep SELinux set to Enforcing.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 16
    There have been a bunch of discussions around SELinux Permissive mode recently in the Audio Mod & Kernel circles. I'd like to start a discussion here around the risks associated with Root and SELinux. I've done some research already (as of 5/15/2017) and will include my notes and conclusions below, but they may be subject to change as new information comes up.

    The main question I wanted to answer is this:
    Is being Rooted essentially the same as being in Permissive mode?

    Background:
    Security is always more secure in serialized layers; meaning that each layer has to be passed through one after the other. Unix provides its standard permissions as a single layer of security (for the security buffs out there this is a Discretionary Access Control system). SELinux adds an additional layer of security on top of the standard Unix Permissions by providing a Mandatory Access Control system through the enforcement of a global permissions policy. The main purpose of SELinux is to prevent escalation of privilege attacks, for example to prevent an MMS app from modifying Network Settings or accessing other resources not related to MMS. So SELinux essentially confines all apps (system or otherwise) to a realm of legitimate activity.

    The SELinux Policy is actually a 'compiled' (more serialized than compiled, but it's referred to as compiled) version of a human-readable text version of the permissions contained in the policy. On a Stock Unrooted device the SELinux Policy is distributed with the ROM and is never modified except for during ROM upgrades if necessary. This provides the highest level of security (assuming the ROM provides a tight policy) since the SELinux Policy should only contain permissions for legitimate activities according to the device manufacturer and/or carrier. So SELinux would, in theory, restrict any malicious app to safe activities, preventing serious harm to your device & data.

    Since the SELinux Policy restricts full access to the device in order to achieve root some of those restrictions need to be bypassed. How this is performed varies, but the end goal is the same : inject new permissions into the SELinux Policy to allow the root implementation full access to the device. If the root implementation is ethical then it should only inject permissions related to providing root access. Since root apps will likely require permissions not included in a device's Stock SELinux Policy most root implementations provide tools for injecting permissions into the SELinux Policy at runtime (selinux-inject, supolicy & magiskpolicy). Most root implementations also provide locations for startup scripts which are executed in a root context. These tools and scripts are used legitimately by the root implementation to maintain root access and by root apps to maintain stable functionality.

    SELinux provides three modes : Enforcing, Permissive & Disabled (not covered in this discussion). In Enforcing mode SELinux will deny and log any requests for permissions against the SELinux Policy. Enforcing mode is meant for production devices (or devices for end users). In Permissive mode SELinux will only log the requests against the SELinux Policy, but will not deny any requests. Permissive mode is meant for development devices so that developers can isolate the appropriate permissions to include in the SELinux Policy before enabling Enforcing mode and shipping the device for production. While in Permissive mode the logs still capture whether a request would be allowed or denied and can be accessed through the 'dmesg' command by filtering for lines with 'avc' in them.

    Possible Attack Vectors:
    For a Stock device in Enforcing mode the main attack vector would be SELinux itself and the Unix standard permissions since those are the mechanisms on the device which can allow or deny full device control. This would likely require a very high degree of sophistication and social engineering since the malicious app would essentially be installing a root implementation for it to use to bypass SELinux.

    For Rooted devices in Enforcing mode the main attack vectors are the root implementation and/or the user. In theory a malicious app would need to convince the user to grant it root access. From there the malicious app can utilize the tools and script locations provided by the root implementation to inject the permissions it needs for full device control. If the root implementation can be exploited directly then the malicious app may not need the user to grant root access. Another alternate attack vector could be other vulnerable apps, such as startup script compatibility apps. These apps usually require root access so the scripts are run at startup in a root context, but there is no guarantee that the location the startup scripts are placed for that app requires root access to add scripts. So a malicious app could add a script to that location and have its malicious code/permissions executed that way.

    For Rooted devices in Permissive mode the main attack vectors are still the root implementation and/or the user. Except that in this situation the malicious app would never need to inject any permissions into the SELinux Policy. Instead it would only need to be granted root access to achieve full device control. The alternate attack vector also still applies.

    Quick Summary (or TL;DR):
    - Stock & Enforcing --> high level of security; main attack vector is SELinux implementation itself to bypass privilege escalation protection
    - Rooted & Enforcing --> moderate level of security; SELinux has already been compromised, main attack vector is root implementation and/or the user in order to acquire root access for full device control, once root access is acquired inject policy permissions for full device control
    - Rooted & Permissive --> low level of security; SELinux is only logging the policy requests and won't deny anything, main attack vector is root implementation and/or the user in order to acquire root access for full device control
    - Stock & Permissive --> Unsure... ?

    Conclusion:
    Root is a responsibility and opens you to exploits and vulnerabilities which are handled with compensating controls on Stock devices. My current opinion is that running Root & Enforcing is not the same as running Root & Permissive, but it is very close since the gatekeeper to full device control becomes the root implementation & manager. An attacker needs a higher level of sophistication to interact with the appropriate tools and inject the necessary permissions. But it also shifts more responsibility onto the user since it is up to the user which apps they install and which are granted root access. Root & Enforcing mode provides protection from system attacks (such as MMS attempting to modify Network Settings) and reasonable app security provided that the user restricts root access to legitimate apps & keeps an eye on security.

    Sources:
    - https://source.android.com/security/selinux/
    - https://android.stackexchange.com/q...elinux-is-in-permissive-mode-what-should-i-be
    - https://su.chainfire.eu/#selinux-policies-supolicy
    - Magisk Scripts : https://forum.xda-developers.com/showpost.php?p=68967705&postcount=2
    - SuperSu Scripts : https://su.chainfire.eu/#updates-sud
    1
    @Jman420, you do have the gist of this... But I I'll try my best to explain it a bit more... User Friendly :)

    Apart from a typical kernel modification, the actual SELinux (Security-Enhanced Linux) tools/policies are all located in one file "/sepolicy". That file, simply, contains the instructions for the actual control mechanisms typically located in the "/sys/fs/selinux/" directory.

    Obtaining/Gaining proper Root within the device doesn't mean that your granted Root control in one of the devices features within the, commonly referred to as, MAC (Mandatory Access Control) system.

    Individuals often confuse the devices Root access with certain, higher privileged roles, that are assigned to the devices Security-Enhanced Linux. The individual with a Rooted device typically confuses the two separate device privileges and should keep in mind that an Android does have multiple device privileges.

    But that does mean that restricting root access to a folder means that some additional countermeasures need to be implemented. It just means that those separate policies are typically determined by way of the devices "Kernel" that outlines the users ability to make modifications to the devices "Security-Enhanced Linux" (aka SELinux).

    The following URL does explain this in a great way:

    Security-Enhanced Linux in Android

    Though, you should keep in mind, that the above URL is a start but, if you do a little searching on the Internet, you should be able to locate other websites that explains the SELinux (Security-Enhanced Linux) in different ways that may be in more of a "layman's terms" that is better understood for some non-technical or less-technical minds.


    "Live Long and Prosper..."
    ~Ambassador S'chn T'gai Spock

    Sent via Communicator [D2VZW] from the Bridge of the U.S.S. Enterprise
    1
    I know this is an old thread, but the question came to me after I installed a custom rom on my device. I was using AospExtended based on Nougat up to yesterday, now I installed a build based on Oreo. The prior versions I was using were always running in SELinux enforcing mode, which suits me because I don't really want to root my device or compromise it's security in any way (as if installing a custom ROM wasn't compromising it enough already). To my surprise, the latest ROM I flashed runs in SELinux permissive, but I installed the first off the bat application to check for root, and my device is reported as not rooted. But it still runs permissive, so I'm confused. What does that mean for me? The way I understand this discussion, having root and SELinux restrictive would still confine root access to some constraints, whereas with SELinux permissive, a malicious piece of software could theoretically do whatever it pleases. Correct?
    1
    I know this is an old thread, but the question came to me after I installed a custom rom on my device. I was using AospExtended based on Nougat up to yesterday, now I installed a build based on Oreo. The prior versions I was using were always running in SELinux enforcing mode, which suits me because I don't really want to root my device or compromise it's security in any way (as if installing a custom ROM wasn't compromising it enough already). To my surprise, the latest ROM I flashed runs in SELinux permissive, but I installed the first off the bat application to check for root, and my device is reported as not rooted. But it still runs permissive, so I'm confused. What does that mean for me? The way I understand this discussion, having root and SELinux restrictive would still confine root access to some constraints, whereas with SELinux permissive, a malicious piece of software could theoretically do whatever it pleases. Correct?

    Ah, so someone finally falls into the 'Stock & Permissive' category that I didn't cover in the OP.

    First, to answer your easy question... Correct, having SELinux enforcing with root would require a malicious app to first obtain root access and then inject necessary SELinux permissions to obtain full device control (or whatever parts it wanted). With SELinux permissive and root the malicious app would probably only need to obtain root access for full device control (and possibly not even that, depending on what it wants to do).

    Now... for your SELinux permissive without root situation... to be honest I'm not really sure... You are definitely at higher risk than someone with SELinux enforcing without root, but there (in theory) isn't an SELinux context to serve root access. To obtain full device control a malicious app would need to root your device, which may not be very difficult considering that SELinux is not enforcing any permissions. For partial control... a malicious app may not need to do much of anything other than be installed, again because SELinux isn't enforcing anything. I think in this context it would really depend on what the malicious app is trying to do... if it is stuff that an app can normally do, but it hasn't asked for the permissions then it may be still able to that stuff. But if its an activity that requires root access it would still fail since no root app or context exists. (Need to point out that all of this is just theory... I haven't done any real research or put hard thought into this scenario.)
    1
    I'm happy to be the first to fall into that hole ;) although I'm pretty sure I'm not the only person using this particular ROM as it currently is. I know the dev is working hard to clear up the policy so that he can turn SELinux back into enforcing, but he probably still has a way to go. Till that happens I'm probably not going to install any sensitive stuff on my phone just as a precaution. It would be really interesting to hear some expert opinions on the matter. Or maybe - in the spirit of true science - there's an experiment I could conduct on my phone to see how compromised it's security is?

    Indeed, I agree. Although I am a security professional, I would hardly consider myself a Linux or SELinux expert. I'm sure there are experiments that can be run to determine the level of exposure that Stock Permissive would give... but none that I know of off-hand. Unfortunately I am incredibly busy at work for the next couple of months and likely won't have time to research or investigate.