Note:

device tree patches are required, this patch includes such for Nexus 5,6,9,
but it should be an easy pattern to follow for other devices.
Missing file is the actual su binary, generated from source as follows;
https://github.com/seSuperuser/Superuser
** copy the su binary into your device's device tree, i.e. device/moto/shamu/

Apply these patches to AOSP sources initialized to android-6.0.0_r1 or android-6.0.1_r3 release tag.
Generate boot.img using "make bootimage".

For bonus points, use the verity_key file from the FACTORY boot.img, and return fstab.shamu line 53 to its original state. This will RE-ENABLE dm-verity security on your system partition, and without denying you your root!

I have yet to come across a compelling reason why you have to edit the contents of your system partition... your various executable binaries and libraries can all be stored on your userdata partition. build.prop edits are entirely unnecessary since you can just dump those changes into /data/local.prop.

This patch *does not* re-enable the ability to re-load the sepolicy. In my opinion, a correctly crafted sepolicy will not require this. The ability to reload the selinux policy is a massive security hole on any device with root access -- any application that gets their hands on root can do *anything* to your device otherwise. Leaving the selinux policy fixed will prevent them from modifying your boot partition, and leaving dm-verity enabled will make any unauthorized changes to your system partition very very obvious so that you can take immedate action and reinstall the factory system image. Note: This characteristic makes this boot image entirely incompatible with that "binary" implementation of root access control software... at least in current (as of time of writing) incarnation.


So what is with all the changed lines with neverallow lines?
Its like this; when google set up the su-via-adb access for debug builds, the kinda took the lazy way out. Its a bit of a weird lazy way though. What they did, is they set the su context to permissive, and then set dontaudit rules for basically every message that would get spit out to the kernel security audit. That is pretty weird, since those dontaudit rules are trivially turned into allow rules such that the domain can be maintained in enforcing mode. When they are turned into allow rules, they conflict with a huge number of the neverallow rules, so we are just adding an exception for the su domain to them.

The thing to keep in mind about adding the su domain exception to all of those neverallow rules, is that it DOES NOT actually elevate the powers of root, OR of the domain represented by that file the neverallow rules are found it. A neverallow rule is not an actual selinux rule. It is used when compiling the rules into the sepolicy binary as a verification step to make sure you didn't accidentally add something inappropriate. Since the su domain was set to permissive, none of those rules would ever have been denied anyway, and wouldn't even have created an audit, since audit was turned off.