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
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
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
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
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.
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?
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
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
- Kernel commandline boot parameters can be checked by extracting
boot.img. On running OS
cat /proc/cmdline can be used.