Based on your description that the Nexus 5 is rooted, "getenforce" is Enforcing
and denials are captured but operations are successful, my guess is the rooting
tool not only makes itself and "Root explorer" as "init" domain, but also
changes the policy, such as "setprop selinux.reload_policy 1". Although the
overall mode is "Enforcing", the "init" domain may be changed into a per-domain
permissive mode. Can you check if there is an "sepolicy" file under
/data/security/current ? If so, you can adb pull it out and use "sesearch" to
find specific rules related to init domain.
I notice that the "init.environ.rc" is in the rootfs, which is supposed to be
read-only. I guess that the rootfs "/" has also been remounted as read-write.
But this should not be persistent after reboot.
On Sunday, May 17, 2015 10:26 PM, 食肉大灰兔V5 <[email protected]> wrote:
> 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=file05-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=file05-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=file05-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=file05-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=file05-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 <[email protected]>
wrote:
On May 17, 2015 8:30 PM, "食肉大灰兔V5" <[email protected]> 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 <[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:
>> 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
> [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].
