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> 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.
