On 05/18/2015 02:14 PM, william.c.robe...@linux.intel.com wrote: >> On 05/18/2015 01:54 PM, william.c.robe...@linux.intel.com 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. >
Correct, however in the SuperSU case at least, they aren't trying to hide anything; they are just making their package portable across all devices by dynamically modifying the original device policy as minimally as possible rather than trying to supply a complete /sepolicy file for each supported device. _______________________________________________ Seandroid-list mailing list Seandroid-list@tycho.nsa.gov To unsubscribe, send email to seandroid-list-le...@tycho.nsa.gov. To get help, send an email containing "help" to seandroid-list-requ...@tycho.nsa.gov.
