Android 6.0 Kernel root requirements.

[chairshot215]

Have a feeling I will figure this out before answered and probably some snide smartest person in the room syndrome remarks but could help save me and some others time so going to bite the bullet and ask anyway. With Android 6.0 what makes some Kernels compatible for root and others not. Have read some tidbits in otherwise unreliable sources it has to do with Selinux being set for permissive mode. If true is this in the Kernel or can it be set in the Ramdisk? Link to a commit would be extremely helpful.

Otherwise have 3 builds going now. If correct pretty sure one of the 3 will work but confirmation makes me feel better.

 

[buckmarble]

Have a feeling I will figure this out before answered and probably some snide smartest person in the room syndrome remarks but could help save me and some others time so going to bite the bullet and ask anyway. With Android 6.0 what makes some Kernels compatible for root and others not. Have read some tidbits in otherwise unreliable sources it has to do with Selinux being set for permissive mode. If true is this in the Kernel or can it be set in the Ramdisk? Link to a commit would be extremely helpful.

Otherwise have 3 builds going now. If correct pretty sure one of the 3 will work but confirmation makes me feel better.

https://github.com/Elite-Kernels/elite_shamu/commit/c91d04bb34b327d66212090a0de36aa29bd6840b

Done in kernel

Sent from my Nexus 6 using Tapatalk

 

[chairshot215]

https://github.com/Elite-Kernels/elite_shamu/commit/c91d04bb34b327d66212090a0de36aa29bd6840b

Done in kernel

Sent from my Nexus 6 using Tapatalk

Thanks had worked out in one of the three I was testing using SuperSu 5.1. Why I am trying to school myself on new changes it seems I am now encrypted by default using the same files (fstab.shamu) that I used in 5.1.1. Are you aware of any changes now required for 6.0? admittedly am using the same Anykernel set up as I had with Lollipop and am new to using the Anykernel method for flashing kernels as in the past would just compile the boot.img. Honestly had been used to releasing my own Roms and not just Kernels so some of these things are new.

Sorry I am not ashamed to admit when something simple is throwing me for a loop and ask even if makes me look like a dumb ars.

 

[Gandalf]

Thanks had worked out in one of the three I was testing using SuperSu 5.1. Why I am trying to school myself on new changes it seems I am now encrypted by default using the same files (fstab.shamu) that I used in 5.1.1. Are you aware of any changes now required for 6.0? admittedly am using the same Anykernel set up as I had with Lollipop and am new to using the Anykernel method for flashing kernels as in the past would just compile the boot.img. Honestly had been used to releasing my own Roms and not just Kernels so some of these things are new.

Sorry I am not ashamed to admit when something simple is throwing me for a loop and ask even if makes me look like a dumb ars.

to remove force encryption you need to change "forceencrypt" to "encryptable" in the fstab for userdata. This will not automagically decrypt you, so if you flashed factory images, you will be encrypted again. You will need to format data in TWRP to decrypt again.

 

[chairshot215]

I just pushed my anykernel to Github so could post but is pretty much what I had done. what I had done was working after either format data or performing a factory reset with 5.1.1. Starting to think maybe my factory image flash had gone wrong. Could just be a change I am not aware of but did not see the optimizing apps screen after wiping. What I had essentially done is after flashing factory image rebooted bootloader and before booting the first time flashed TWRP installed my Kernel, flashed SuperSu 5.1 and then did a full cache and data wipe.

Admittedly with anykernel I had started by downloading another Kernel, forget which one and then removed or adding what I believed should for my Kernel. So far besides the little encryption issue seems to be working out OK. Trying to keep the Kernel as effective as possible with the fewest possible trade off’s. Not much original work in the sense a lot has already been done but have done lots of testing for efficiency.

Anykernel
https://github.com/Starship-Android/anykernel

 

[doitright]

Have a feeling I will figure this out before answered and probably some snide smartest person in the room syndrome remarks but could help save me and some others time so going to bite the bullet and ask anyway. With Android 6.0 what makes some Kernels compatible for root and others not. Have read some tidbits in otherwise unreliable sources it has to do with Selinux being set for permissive mode. If true is this in the Kernel or can it be set in the Ramdisk? Link to a commit would be extremely helpful.

Otherwise have 3 builds going now. If correct pretty sure one of the 3 will work but confirmation makes me feel better.

https://github.com/Elite-Kernels/elite_shamu/commit/c91d04bb34b327d66212090a0de36aa29bd6840b

Done in kernel

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.

 

[doitright]

So I've actually been working on this myself, since it is impossible to trust chainfire or his new employer (who is systematically buying up ALL of the root provisioning software for Android), and I have come up with this as an interim step;

diff --git a/app.te b/app.te
index 40de074..98bb663 100644
--- a/app.te
+++ b/app.te
@@ -283,7 +283,7 @@ neverallow appdomain { domain -appdomain }:process
 # Transition to a non-app domain.
 # Exception for the shell domain and the su domain, can transition to runas,
 # etc.
-neverallow { appdomain -shell userdebug_or_eng(`-su') } { domain -appdomain }:process
+neverallow { appdomain -untrusted_app -shell userdebug_or_eng(`-su') } { domain -appdomain }:process
     { transition dyntransition };
 
 # Write to rootfs.
diff --git a/domain.te b/domain.te
index 0f6c6da..b1d7c41 100644
--- a/domain.te
+++ b/domain.te
@@ -396,7 +396,7 @@ neverallow domain { file_type fs_type dev_type }:{ lnk_file fifo_file sock_file
 # Nobody should be able to execute su on user builds.
 # On userdebug/eng builds, only dumpstate, shell, and
 # su itself execute su.
-neverallow { domain userdebug_or_eng(`-dumpstate -shell -su') } su_exec:file no_x_file_perms;
+neverallow { domain -init -untrusted_app userdebug_or_eng(`-dumpstate -shell -su') } su_exec:file no_x_file_perms;
 
 # Do not allow the introduction of new execmod rules. Text relocations
 # and modification of executable pages are unsafe.
diff --git a/init.te b/init.te
index 41eafe2..e7dd87a 100644
--- a/init.te
+++ b/init.te
@@ -123,7 +123,7 @@ allow init security_file:dir { create setattr };
 
 # Reload policy upon setprop selinux.reload_policy 1.
 # Note: this requires the following allow rule
-#   allow init kernel:security load_policy;
+allow init kernel:security load_policy;
 # which can be configured on a device-by-device basis if needed.
 r_dir_file(init, security_file)
 
@@ -283,4 +283,5 @@ neverallow init shell_data_file:lnk_file read;
 neverallow init app_data_file:lnk_file read;
 
 # init should never execute a program without changing to another domain.
-neverallow init { file_type fs_type }:file execute_no_trans;
+allow init { file_type fs_type }:file execute_no_trans;
+allow init kernel:security read_policy;
diff --git a/keystore.te b/keystore.te
index 83a0e85..d742d30 100644
--- a/keystore.te
+++ b/keystore.te
@@ -24,7 +24,7 @@ selinux_check_access(keystore)
 ###
 
 neverallow { domain -keystore } keystore_data_file:dir ~{ open create read getattr setattr search relabelto ioctl };
-neverallow { domain -keystore } keystore_data_file:notdevfile_class_set ~{ relabelto getattr };
+neverallow { domain -keystore -init } keystore_data_file:notdevfile_class_set ~{ relabelto getattr };
 
 neverallow { domain -keystore -init } keystore_data_file:dir *;
 neverallow { domain -keystore -init } keystore_data_file:notdevfile_class_set *;
diff --git a/su.te b/su.te
index d4a488b..1d1f6da 100644
--- a/su.te
+++ b/su.te
@@ -7,6 +7,7 @@ userdebug_or_eng(`
   # wrapped to ensure that it does not exist at all on -user builds.
   type su, domain, mlstrustedsubject;
   domain_auto_trans(shell, su_exec, su)
+  domain_auto_trans(untrusted_app, su_exec, su)
 
   # Allow dumpstate to call su on userdebug / eng builds to collect
   # additional information.
diff --git a/vold.te b/vold.te
index b22436f..fa1a879 100644
--- a/vold.te
+++ b/vold.te
@@ -164,7 +164,7 @@ allow vold self:capability sys_chroot;
 allow vold storage_file:dir mounton;
 
 neverallow { domain -vold } vold_data_file:dir ~{ open create read getattr setattr search relabelto ioctl };
-neverallow { domain -vold } vold_data_file:notdevfile_class_set ~{ relabelto getattr };
+neverallow { domain -vold -init } vold_data_file:notdevfile_class_set ~{ relabelto getattr };
 neverallow { domain -vold -init } vold_data_file:dir *;
 neverallow { domain -vold -init } vold_data_file:notdevfile_class_set *;
 neverallow { domain -vold -init } restorecon_prop:property_service set;

Some of those are what reverse engineering I've managed to accomplish on the policy changes required for supersu, and some of them are working towards a better root control infrastructure.

In any case, if you patch platform/external/sepolicy with that, then run a "make bootimage", it *WILL* actually work with supersu.
** note: make sure that you repo init against the android-6.0.0_r1 release branch if you want it to actually be compatible with factory builds. Master has a LOT of MAJOR changes since then and it does not work.

Also note: don't forget to patch platform/device/moto/shamu/fstab.shamu to kill the verify and optionally forceencrypt parameters.

 

[doitright]

I'm just going to leave these two links right here....

https://github.com/lbdroid/AOSP-SU-PATCH
https://github.com/phhusson/Superuser

That will yield an ENFORCING, and NON-RELOADABLE selinux policy, allowing root, and all bundled into the boot.img in order to maintain the integrity (dm-verity) of the system image!

Take THAT Coding Code Mobile Technology LLC!!!!!

And for people who want to know the true history of things (rather than worshiping people who distribute binaries....), please read this; http://www.koushikdutta.com/2008/11/fixing-su-security-hole-on-modified.html and then look at the github label (that says "forked from") on the Superuser repository I linked above.

 

[chairshot215]

I'm just going to leave these two links right here....

https://github.com/lbdroid/AOSP-SU-PATCH
https://github.com/phhusson/Superuser

That will yield an ENFORCING, and NON-RELOADABLE selinux policy, allowing root, and all bundled into the boot.img in order to maintain the integrity (dm-verity) of the system image!

Take THAT Coding Code Mobile Technology LLC!!!!!

And for people who want to know the true history of things (rather than worshiping people who distribute binaries....), please read this; http://www.koushikdutta.com/2008/11/fixing-su-security-hole-on-modified.html and then look at the github label (that says "forked from") on the Superuser repository I linked above.

Thanks I have been bed ridden for a bit but will look over all these things. In short my last build I first flashed chainfires boot.img and rooted before flashing my Kernel. Was able to do this without putting my Kernel into permissive mode. Had also unpacked the chainfire boot.img and used a few things in my boot image and used Meld and made a few other edits based on chainfires boot.img. Still having an issue with encryption being forced that just has me baffled. Was otherwise a temporary quick fix for not having to put the Kernel into permissive mode.

Definitely appreciate all the feedback and am learning allot so thanks for that everyone.

Otherwise the Encryption is driving me mentally insane. Like straitjacket throwing myself around a small room with rubber walls and a door with a slot that keeps opening with a tray of drugs and food sliding in insane. It has become so frustrating.

this is the fstab I am using and see know issue. Have also tried Despair, Vortex and the fed_patcher patch not to mention Chainfires Kernel for Root and no matter how many times I wipe data or factory reset it is always encrypted. If it was not knowing the encryption is done via software would swear something is wrong with the phone. Have also changed up TWRP 3 times as noticed I no loner see updating apps but that is also the same in that encription is still forced

https://github.com/Chairshot215/anykernel/blob/master/ramdisk/fstab.shamu

 

[doitright]

The problem you are running into, is that recovery doesn't actually *format* the userdata partition, which means that a factory reset from recovery won't *remove* the encryption. The reason it doesn't format is to prevent the deletion of /data/media directory, which gets mapped to /sdcard.

What you need to do, is reboot to bootloader, and run "fastboot format userdata".

If you aren't permissive, then the big thing you must have taken from chainfire's boot.img, is the sepolicy file. He only actually changed two files; sepolicy and fstab.shamu.

The thing to be aware of, though, is that his supersu, despite running selinux enforcing, is actually putting a lot of domains into permissive. When you go through your kernel audit log, you should pay attention to the end of the audit log where it says "permissive=1" or "permissive=0". You will find a lot of "permissive=1". Using *my* sepolicy, which is NOT compatible with his supersu, you will find that ALL domains remain enforcing, yet we aren't increasing the authority of any domain besides the "su" domain, AND, there will actually be far fewer denials against root/su. On top of that, I actually block the su domain from messing with kernel security. In other words, we do NOT allow the su domain to change selinux to permissive, OR to reload the policy. Both of those ARE permitted in chainfire supersu, which is incredibly dangerous, given how root is typically used on Android.

To put that into perspective, the ability to change the enforcement status or reload the policy, makes it possible for a malicious application to modify the boot.img to disable dmverity on the system partition, and compromise the system partition. My approach makes it possible to maintain the integrity of the boot partition and therefore maintain dmverity on the system partition, while providing root access. This makes unauthorized changes to the system partition immediately obvious and ineffective, since dmverity will refuse to read changed data, instead returning an i/o error.

The verity keys are actually stored on the boot.img, which means that it is still possible to make *intentional* changes to the system partition (through regenerating the key), and prevent unauthorized changes.

I've been considering adding a new domain to the effect of "su_sensitive" that will enforce strong password input for every authorization request in order to grant kernel security permission, but it remains to be seen if this would even be helpful to anyone.

 

[Cheapo2311]

How do you even edit a kernel? If you could explain, please do so.