> It looks like the exploit sets the security ID for the process to init. Notice scontext is init. I'm not sure if the actions that are occurring are actually failing or not,
I can successfully read (or write) the "init.environ.rc" file using "RootExplorer" app. > I'm not familiar with those rooting apps,perhaps they patch the function returns or something. As far as I know, SELinux (or LSM) adds access control to hundreds of system calls. Will a root tool patch all these functions? executing "setenforce 0" is a better way than that. My testbed is Nexus 5 with AOSP 5.1.0 R3. Root tool can be downloaded here: http://pan.baidu.com/s/1jGAFzca (press 下载(6.3M) button) > Are you actually creating and writing those files? No, I just attempted to read the file (by tapping the "View" button), I don't understand why SELinux reports perms like "write, create" either, as I didn't perform such operations. Then afterwards, I also try to write the file (by tapping the "Open in Text Editor" in RootExplorer, and change & save the file), SELinux logs are as below. This time seems to be less weird than "read", as we see the "rename, create, write" ops. But same with previous, SELinux is bypassed and "init.environ.rc" is actually changed. 05-18 05:01:29.860: W/mv(20977): type=1400 audit(0.0:415): avc: denied { rename } for name="init.environ.rc" dev="rootfs" ino=6358 scontext=u:r:init:s0 tcontext=u:object_r:rootfs:s0 tclass=file 05-18 05:01:29.890: W/rt.sh(5838): type=1400 audit(0.0:416): avc: denied { create } for name="init.environ.rc" scontext=u:r:init:s0 tcontext=u:object_r:rootfs:s0 tclass=file 05-18 05:01:29.890: W/rt.sh(5838): type=1400 audit(0.0:417): avc: denied { write } for name="init.environ.rc" dev="rootfs" ino=75397 scontext=u:r:init:s0 tcontext=u:object_r:rootfs:s0 tclass=file 05-18 05:01:29.890: W/rt.sh(5838): type=1400 audit(0.0:418): avc: denied { read } for name="temp" dev="mmcblk0p28" ino=1475011 scontext=u:r:init:s0 tcontext=u:object_r:app_data_file:s0 tclass=file 05-18 05:01:29.890: W/rt.sh(5838): type=1400 audit(0.0:419): avc: denied { open } for name="temp" dev="mmcblk0p28" ino=1475011 scontext=u:r:init:s0 tcontext=u:object_r:app_data_file:s0 tclass=file 05-18 05:01:29.920: W/chmod(20981): type=1400 audit(0.0:420): avc: denied { setattr } for name="init.environ.rc" dev="rootfs" ino=75397 scontext=u:r:init:s0 tcontext=u:object_r:rootfs:s0 tclass=file On Mon, May 18, 2015 at 11:41 AM, William Roberts <bill.c.robe...@gmail.com> wrote: > > On May 17, 2015 8:30 PM, "食肉大灰兔V5" <hslu...@gmail.com> 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? > > It looks like the exploit sets the security ID for the process to init. > Notice scontext is init. I'm not sure if the actions that are occurring are > actually failing or not, I'm not familiar with those rooting apps,perhaps > they patch the function returns or something. Are you actually creating and > writing those files? > > > > > 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> > 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. > >
_______________________________________________ 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.
