Effectively circumventing SELinux policies
At the end of last May, Sean Fish, a security researcher cshared information andn his blog about a method he found to bypass the SELinux security module.
In his blog post, cHe shared a demonstration of how it is possible to bypass the prohibition to load kernel modules, implemented in specific SELinux rules on one of the studied devices (it is not specified which device it is and how much the problem affects SELinux rules in firmware and distributions).
For those unaware of SELinux (Security Enhanced Linux) should know that this eIt's a security module for the Linux kernel, which improves the security of the system and, in case of a security breach, prevents it from spreading throughout the system.
SELinux works in three modes; "Disable, Permissive, and Enforcing." In Disable mode, SELinux remains completely disabled. If SELinux is enabled, it will be in Permissive mode or Executor mode. In permissive mode, SELinux will only monitor the interaction. In Enforcing mode, SELinux will also filter interaction with monitoring.
Its security rigidity can be understood from the fact that with SELinux, that even if the system is compromised, files that are not given access cannot be accessed.
Having already explained very superficially SELinux, about the bypass Sean Pesce mentions that blocking modules in the SELinux rules involved relied on restricting access to the system call finit_module, which allows a module to be loaded from a file and is used in utilities like insmod.
I've recently been eyeing an undisclosed Linux-based device as a personal weekend side project. Using some simple techniques that I won't discuss here, I gained root shell access. To avoid revealing unnecessary details about the target implementation, information such as file names and SELinux contexts have been changed in the article.
It is mentioned that as such it is not necessarily mandatory to disable SELinux, but to avoid a lot of complications a custom kernel module is loaded "would be best". But not in this case, since to bypass it he shares that I first decide to clone one of the existing kernel modules from the device's file system using a script and which is patched in the module_init function which can also be used to load kernel modules directly from a buffer in memory.
Connecting with my reverse shell, I quickly realized that the system had SELinux enabled. Although the policy wasn't as strict as the standard policy you might find on a typical Android device, it was strict enough to prevent me from doing a lot of useful things (for example, mounting file systems and accessing files in /etc/ ). Fortunately, I was able to write and execute files in /tmp/ , so I still had an easy way to create and run custom tools.
He further mentions that there are two different system calls that can be used to load a kernel module: int init_module which loads a kernel module stored in memory, while int finit_module loads a kernel module from disk.
With this, the possibility of loading kernel modules is taken advantage of, which can be compiled as custom modules to do something more advanced and with the necessary configurations, a successful execution of the kernel with user space access can be obtained.
The SELinux context is not being removed; rather, we're transitioning into the startup task context (generally speaking, this context probably has very few, if any, restrictions).
To demonstrate the method, a working prototype was prepared which allows executing kernel-level code by loading its module and completely disabling SELinux protection, if you have limited root access to the system using SELinux.
Finally, if you are interested in being able to learn more about it, you can check the details in the original publication at the following link.