Revisit kernel setenforce

Kernel userspace helpers may be spawned running in the kernel
SELinux domain. Those userspace helpers shouldn't be able to turn
SELinux off.

This change revisits the discussion in
https://android-review.googlesource.com/#/c/71184/

At the time, we were debating whether or not to have an allow rule,
or a dontaudit rule. Both have the same effect, as at the time we
switch to enforcing mode, the kernel is in permissive and the operation
will be allowed.

Change-Id: If335a5cf619125806c700780fcf91f8602083824

domain.te

@@ -169,7 +169,8 @@ neverallow { domain -init } kernel:security load_policy;
 # init starts in kernel domain and switches to init domain via setcon in
 # the init.rc, so the setenforce occurs while still in kernel. After
 # switching domains, there is never any need to setenforce again by init.
-neverallow { domain -kernel } kernel:security { setenforce setcheckreqprot };
+neverallow domain kernel:security setenforce;
+neverallow { domain -kernel } kernel:security setcheckreqprot;
 
 # No booleans in AOSP policy, so no need to ever set them.
 neverallow domain kernel:security setbool;

kernel.te

@@ -11,7 +11,9 @@ allow kernel unlabeled:filesystem mount;
 allow kernel fs_type:filesystem *;
 
 # Initial setenforce by init prior to switching to init domain.
-allow kernel self:security setenforce;
+# We use dontaudit instead of allow to prevent a kernel spawned userspace
+# process from turning off SELinux once enabled.
+dontaudit kernel self:security setenforce;
 
 # Set checkreqprot by init.rc prior to switching to init domain.
 allow kernel self:security setcheckreqprot;