> On 05/18/2015 01:54 PM, [email protected] wrote: >>> After checking http://su.chainfire.eu, I found this quote >>> 5.5.2. Default patches >>> Aside from various small policy patches that open various communication >>> paths between the su processes, the major changes to the stock >>> policy supolicy makes is making init, init_shell (v2.22+), >>> and recovery permissive. >>> I am curious if anyone knows more about this "supolicy", looks like >>> SuperSU does patch the default policy to make "init" permissive and >>> maybe >>> also add some permissions to its supolicy as well.  >> >> I am not going to review this policy, however sediff would be a great >> place for you to start at. I would extract the sepolicy from the ramdisk >> (inside of boot.img) of the original factory image and then sediff it >> with >> the one extracted from the ramdisk of your (rooted) image. >> >> This might give you a good place to analyze what has been done. However, >> if it is as what has been said and init is in permissive domain, then it >> doesn't matter what rules are added, init is no longer confined. Thus, >> marshaling commands for init to execute, or something running as root >> in >> that domain (u:r:init:s0) would have full control. However, one would >> observer denials but selinux is only logging for that domain and not >> actually taking action. > > They might not be modifying the /sepolicy file in the boot image but > rather injecting a modified policy at startup from their su daemon > running in the init domain. sepolicy-inject shows how to take an > existing policy, modify it to e.g. make a domain permissive or to add > rules, and then output the modified policy that can be loaded into the > kernel, so they could have used that code as an example. To be sure > that you are examining the actual policy loaded into the kernel, you > should adb pull /sys/fs/selinux/policy rather than /sepolicy.
Good point Stephen. Additionally, the paranoid part in me will also caveat this. Since the boot.img has been repackaged, their is always the possibility they could lie over they interface and send the one from the ramdisk. However, considering that they left SELinux on, and doing something, it would be highly unlikely they would have done that. But, as has been said before, once the kernel has been mucked with anything done from userspace is suspect. > _______________________________________________ Seandroid-list mailing list [email protected] To unsubscribe, send email to [email protected]. To get help, send an email containing "help" to [email protected].
