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.
On Monday, May 18, 2015 6:14 AM, Jason Zaman <[email protected]> wrote:
Chainfire has documented everything about how the selinux stuff for
root works here: http://su.chainfire.eu/#selinux
No exploit or vulnerability is required at all. You just unlock the
bootloader and flash the images. It then runs a little daemon very early
on in a high priority domain and adds to the policy if required.
-- Jason
On Mon, May 18, 2015 at 11:26:47AM +0800, 食肉大灰兔V5 wrote:
> Hi there.Â
> At first I held the same opinion with you that the root tools (like
> Chainfire's SuperSU or Kingroot) have to use vulnerabilities to gain
> root and disable SELinux from its restriction (by executing "setenforce
> 0). But when I used "Root Explorer" to explore a system file
> (init.environ.rc) after rooting, I found that SELinux is still
> enforced, getenforce command returns "Enforcing". And the logcat
> records the SELinux denials as below. It seems that SELinux is still
> working but it doesn't actually prevent rooting, "Root Explorer" is
> able to read the "init.environ.rc" file. Why these root tools can
> bypass SELinux without disabling it?
> 04-30 19:57:13.408: I/ActivityManager(709): START u0
> {dat=file:///init.environ.rc
> cmp=com.speedsoftware.rootexplorer/.DisplayText (has extras)} from uid
> 10054 on display 0
> 04-30 19:57:13.412: V/WindowManager(709): addAppToken:
> AppWindowToken{49c4614 token=Token{3ee7a867 ActivityRecord{29e2a426 u0
> com.speedsoftware.rootexplorer/.DisplayText t616}}} to stack=1 task=616
> at 1
> 04-30 19:57:13.420: D/audio_hw_primary(190): out_set_parameters: enter:
> usecase(1: low-latency-playback) kvpairs: routing=2
> 04-30 19:57:13.439: W/rt.sh(5838): type=1400 audit(0.0:221): avc:
> denied { write } for name="files" dev="mmcblk0p28" ino=1474930
> scontext=u:r:init:s0 tcontext=u:object_r:app_data_file:s0 tclass=dir
> 04-30 19:57:13.439: W/rt.sh(5838): type=1400 audit(0.0:222): avc:
> denied { add_name } for name="temp" scontext=u:r:init:s0
> tcontext=u:object_r:app_data_file:s0 tclass=dir
> 04-30 19:57:13.439: W/rt.sh(5838): type=1400 audit(0.0:223): avc:
> denied { create } for name="temp" scontext=u:r:init:s0
> tcontext=u:object_r:app_data_file:s0 tclass=file
> 04-30 19:57:13.439: W/rt.sh(5838): type=1400 audit(0.0:224): avc:
> denied { write open } for name="temp" dev="mmcblk0p28" ino=1474875
> scontext=u:r:init:s0 tcontext=u:object_r:app_data_file:s0 tclass=file
> 04-30 19:57:13.449: W/chmod(6236): type=1400 audit(0.0:225): avc:
> denied { setattr } for name="temp" dev="mmcblk0p28" ino=1474875
> scontext=u:r:init:s0 tcontext=u:object_r:app_data_file:s0 tclass=file
> 04-30 19:57:13.468: V/WindowManager(709): Adding window Window{24bc6403
> u0
> com.speedsoftware.rootexplorer/com.speedsoftware.rootexplorer.DisplayTe
> xt} at 6 of 11 (after Window{85f1c5a u0
> com.speedsoftware.rootexplorer/com.speedsoftware.rootexplorer.RootExplo
> rer EXITING})
> 04-30 19:57:13.530: I/ActivityManager(709): Displayed
> com.speedsoftware.rootexplorer/.DisplayText: +106ms
> hsluoyz
>
> On Wed, May 13, 2015 at 9:19 PM, Stephen Smalley <[1][email protected]>
> wrote:
>
> On 05/12/2015 02:15 PM, Stephen Smalley wrote:
> > On 05/12/2015 12:46 PM, é£è大ç°åV5 wrote:
> >> Hi, all
> >>
> >> I noticed that some rooting software can "root" the Android device
> and
> >> provide root access for other apps, like KingRoot 4.0 recently has
> >> successfully rooted my Nexus 5 running AOSP 5.1.0 R3. I wonder
> whether
> >> restricting such rooting conduct is one of SEAndroid's objectives?
> If
> >> yes, then how to protect from it?
> >
> > Depends on what you mean by "root" the Android device.
> > There's a legitimate way to do that for a Nexus device, i.e. boot
> into
> > bootloader mode, run fastboot oem unlock, accept it on the screen,
> wait
> > for userdata to be erased, and then use fastboot to flash any
> partition
> > you like with a custom image containing anything you want. SE for
> > Android isn't going to prevent that, except insofar as the default
> > policy may interfere with its operation unless they reflash the boot
> > image with one containing a custom policy.
> >
> > Then there is the illegimate way to do it, i.e. install an app or run
> > something via adb shell that exploits a vulnerability in Android to
> > escalate privileges and then proceeds to modify /system or other
> > partitions. In some cases, SE for Android can prevent the privilege
> > escalation, but this depends on the nature of the vulnerability
> (kernel
> > or userspace) and whether the vulnerable code is
> reachable/exploitable
> > under the policy. Also, SE for Android can prevent writing to
> /system
> > or other partitions but if they are using a kernel vulnerability and
> > gaining kernel code execution, then they can just disable SELinux (or
> > any other kernel security feature).
> >
> > With regard to detecting or preventing kernel exploits, Samsung KNOX
> has
> > something called TIMA that seeks to detect and protect the kernel via
> > software running in the TrustZone secure world. grsecurity is a
> project
> > that has implemented a number of kernel self-protection features that
> > could potentially be ported to the Android kernel in order to improve
> > its robustness against common flaws.
>
> The other potentially relevant protection mechanism is verified
> boot,
> which, if enabled, will detect tampering with /system or other
> verified
> partitions at boot time. See:
> [2]https://source.android.com/devices/tech/security/verifiedboot/ind
> ex.html
> [3]http://nelenkov.blogspot.com/2014/05/using-kitkat-verified-boot.h
> tml
>
> References
>
> 1. mailto:[email protected]
> 2. https://source.android.com/devices/tech/security/verifiedboot/index.html
> 3. http://nelenkov.blogspot.com/2014/05/using-kitkat-verified-boot.html
> _______________________________________________
> Seandroid-list mailing list
> [email protected]
> To unsubscribe, send email to [email protected].
> To get help, send an email containing "help" to
> [email protected].
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
_______________________________________________
Seandroid-list mailing list
[email protected]
To unsubscribe, send email to [email protected].
To get help, send an email containing "help" to
[email protected].
