2

As in title. I am talking of Kernel, not ROM (plenty of questions dealing with ROM on this site).

I have a OnePlus 7 running stock Android 10 and prefer a custom kernel. Of late, OnePlus hasn't released source for kernel and this has played havoc with all custom kernels in OnePlus 7 and other variants. So, I want to flash a kernel that is independent of the changes One Plus makes.

Only problem is that it is SELinux permissive and therefore I want to understand the security risks before flashing it.

Edit:
As requested in comments (deleted) :

-# zcat /proc/config.gz | grep CONFIG_SECURITY_SELINUX
CONFIG_SECURITY_SELINUX=y
# CONFIG_SECURITY_SELINUX_BOOTPARAM is not set
# CONFIG_SECURITY_SELINUX_DISABLE is not set
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=0
- # zcat  /proc/config.gz |grep CONFIG_DEFAULT_SECURITY_SELINUX
CONFIG_DEFAULT_SECURITY_SELINUX=y
-# mount | grep selinuxfs
selinuxfs on /sys/fs/selinux type selinuxfs (rw,relatime)
3
+100

SELinux is a security framework which restricts (kernel and userspace) processes within their domains according to defined policy. So the ultimate goal is to load a working policy, label filesystems with proper contexts and set SELinux enforcing. It doesn't matter who does this; kernel or some userspace process, though the sooner the better. And permissive is an SELinux mode always ready to be switched to enforcing mode. However switching other way may or may not be allowed by the policy.

In other words, kernel being SELinux permissive by itself is not a risk, if the the ROM overrides that to make it Enforcing. What SELinux permissive kernel gives you is a flexibility to flash ROMs that demand SELinux permissive or for any other app that needs it. But it is always advisable to keep the device in SELinux Enforcing state (getenforce on Terminal Emulator will reveal).

Mostly ROM developers build kernel with CONFIG_SECURITY_SELINUX_DEVELOP=y. From kernel configuration:

With this option enabled, the kernel will start in permissive mode (log everything, deny nothing) unless you specify enforcing=1 on the kernel command line. You can interactively toggle the kernel between enforcing mode and permissive mode (if permitted by the policy) via /selinux/enforce.

Some vendors may disable the said configuration or may add enforcing=1 boot parameter to kernel cmdline when building boot.img, so that SELinux is always enforcing even before the very first userspace process init is started. Going a step further ahead Samsung kernel sources are patched with options SECURITY_SELINUX_ENFORCING and ALWAYS_ENFORCE. Other extreme is that SELinux is disabled at all by building with SECURITY_SELINUX_DISABLE=y and writing to /sys/fs/selinux/disable, or by building with SECURITY_SELINUX_BOOTPARAM=y and passing selinux=0 kernel parameter.

Starting kernel in permissive mode gives the ROM developer and end users freedom to set SELinux mode permissive or enforcing on boot (or even during running OS by writing to /sys/fs/selinux/enforce), and develop a policy according to the requirements. That's how userdebug/eng builds of ROMs are debugged. init can be forced to set SELinux permissive on boot by setting androidboot.selinux=permissive boot parameter.

OEMs switch to user builds when releasing stock ROMs once sepolicy is fully developed. init on user builds always sets SELinux enforcing, so it won't boot with SELinux disabled. Custom ROMs, however, usually remain userdebug which allow root access (adb root and /system/xbib/su) and other relaxations. Some more details can be found in What sepolicy context will allow any other context to access it?

So while disabled or permissive SELinux in kernel or ROM makes the device equally vulnerable, a permissive kernel is usually a good thing (at least for ROM developers and power users). Enforcing kernel is an overkill unless the user is glued to the stock ROM throughout life of a device. However if SELinux is disabled (e.g. built without CONFIG_SECURITY_SELINUX=y), stock ROM will get into bootloop.

  • If kernel is built with CONFIG_IKCONFIG, extract-ikconfig shell script can be used to check build configuration without flashing to device. On running OS zcat /proc/config.gz can be used.
  • ROM build type can be checked with getprop ro.build.type.
  • Kernel commandline boot parameters can be checked by extracting boot.img. On running OS cat /proc/cmdline can be used.
| improve this answer | |
  • 1
    As always, a very thorough answer from you. Much appreciated :) – beeshyams Dec 31 '19 at 2:12
  • 1
    For readers - I flashed the kernel in question and happily so after the thorough explanation by Irfan – beeshyams Dec 31 '19 at 3:20
  • 1
    @beeshyams thanks :) – Irfan Latif Jan 5 at 0:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.