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.
