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]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:
> [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:s...@tycho.nsa.gov
> 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
> 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.
_______________________________________________
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.
