Don't know about Kingroot, but SuperSU doesn't use a vulnerability to
gain root; it just uses the legitimate approach that I described of
reflashing the boot image with one that starts a su daemon running in
the init context and either makes the init domain permissive or adds the
necessary permissions to it. That's not something SE for Android would
or could prevent; it is just legitimate usage of the device by the user
and is based on an unlockable bootloader and the ability to flash a
custom boot image.
On 05/17/2015 11:26 PM, 食肉大灰兔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.DisplayText}
> at 6 of 11 (after Window{85f1c5a u0
> com.speedsoftware.rootexplorer/com.speedsoftware.rootexplorer.RootExplorer
> 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 <s...@tycho.nsa.gov
> <mailto:s...@tycho.nsa.gov>> 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:
> https://source.android.com/devices/tech/security/verifiedboot/index.html
> http://nelenkov.blogspot.com/2014/05/using-kitkat-verified-boot.html
>
>
_______________________________________________
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.
