[Nexus 6 Developer Discussion [Developers Only]] doitright:
That is actually a *really bad hack*, since it disables selinux rather than manipulating the policy in an appropriate manner to make root usage possible.

The correct changes are actually *outside* of the kernel itself, in the sepolicy file in the ramdisk.

That sepolicy file is generated based primarily on what is in these repositories;

https://android.googlesource.com/platform/external/sepolicy/

https://android.googlesource.com/device/moto/shamu/+/master/sepolicy/

You see, there are some interesting commits, like this; https://android.googlesource.com/pl...243e5cf4f8898b7acedc24efd58fdcd163e3048^!/#F0

What that one does, is it tells selinux to never allow the sepolicy to be reloaded from the system_server context.

Or this one here, which does the same for the init context;

https://android.googlesource.com/pl...cy/+/6d0e9c8f4ee4f326b2c2851fa2851193fec33a4e

But note: partially reverted here;

https://android.googlesource.com/pl...abd409af0e7d7fb908e5f04fa1ed946e2996dce^!/#F0

That partial reversion actually provides a very useful HINT about it;

# Note: this requires the following allow rule

# allow init kernel:security load_policy;

# which can be configured on a device-by-device basis if needed.

In other words, add that line to this file;

https://android.googlesource.com/device/moto/shamu/+/master/sepolicy/init.te

Then *init* will re-gain the ability to change and reload selinux policies.

HOWEVER, instead of doing that, you might consider going a little further, by enabling THIS in a sortof-user-build;

https://android.googlesource.com/platform/external/sepolicy/+/master/su.te

... and adding domain_auto_trans from untrusted_app to su, and various other adjustments/tweaks.

I think that there is a neverallow rule in there somewhere that will complain if you make that change, so you'll have to kill the neverallow rule... yep, app domain:

https://android.googlesource.com/platform/external/sepolicy/+/master/app.te#286

**note: a neverallow rule is NOT a runtime enforcement directive. selinux defaults to block until a positive allow rule is created. The neverallow rules are used to annoy you when you try to build an sepolicy from source that violates something.

What *I* would do first, is fix that neverallow rule in app, add the auto-transition to su, and run a make bootimg for *USERDEBUG*. You probably should also edit the fstab a bit while you are at it to kill the "verify" parameter from /system, and swap the "forceencrypt" to "encryptable" for /data.

ALL of the changes (besides removing the neverallow rule) can be made in the shamu device tree.

This should produce a boot.img that relaxes selinux a bit to allow su. And from there, the su binary can be root.root/6755, WITH the file context set to su_exec, and you should have root back.... note: su daemon should *NOT* be required with these changes. In fact, you could even proof of concept using "cp /system/bin/sh /system/bin/su; chown root.root /system/bin/su; chmod 6755 /system/bin/su; chcon su_exec /system/bin/su" <-- you will have to look more at the chcon first parameter though, I haven't actually had to use it though, so I'm not entirely sure of what it expects as input. Note the boldness of "proof of concept"... it would be very... unsafe... to actually keep it like that on any device that you actually need to trust.

phhusson's new fork of superuser *should* be able to handle the job, with only minor adjustments to su.c's su_main() function where it is deciding to run connect_daemon() or su_main_nodaemon(). It would need to run su_main_nodaemon() with these changes.