Thank you for your quick reply.
I checked more detail about kingroot.
It using chcon using in their toolbox.
postroot.sh
kr_set_perm() {
#if [ -f "$5" -o -d "$5" ]; then
$MY_TOOLBOX chown $1.$2 $5
if [ -f "/system/bin/chcon" ]; then
$MY_TOOLBOX chcon $3 $5
fi
$MY_TOOLBOX chmod $4 $5
#fi
}
kr_set_perm 0 0 u:object_r:system_data_file:s0 00755 /data/data-lib
kr_set_perm 0 0 u:object_r:system_data_file:s0 00755 /data/data-lib/king
kr_set_perm 0 0 u:object_r:system_data_file:s0 00755
/data/data-lib/com.kingroot.RushRoot
kr_set_perm 0 0 u:object_r:system_file:s0 00755 /system/xbin/krdem
kr_set_perm 0 0 u:object_r:system_file:s0 00755 $1/xbin/supolicy
so, their apk file and other daemon will change system_file,
*Why chcon needed in toolbox?*
It is very vulnerable to hackers..
even that it could change init domain..
Kingroot apk also chaned to init domain during rooting process..
*Is it possible disable chcon in toolbox? *
Thanks.
2015-11-27 23:05 GMT+09:00 William Roberts <bill.c.robe...@gmail.com>:
> From what I can tell, kingroot bundles up exploits on a server and then
> figures out what one will work on your device and tries it.
>
> I would start by patching and fixing all known vulnerabilities for a given
> system.
>
> From there, you state it does a setenforce 0. IIRC only init has this
> capability, so somehow its already gotten its process context to init. You
> could remove this permission and pass enforcing mode via kernel cmdline,
> but that's not going to help you here. If it was able to change process
> context to init, its likely doing kernel exploits and poking at kernel data
> structures. A good example of an exploit that does this would be towel
> root. In a nutshell, any exploit that provides the ability to tamper with
> kernel memory, especially strict cred and the auxillary void * for lsms,
> all bets are off for selinux.
>
> You could start to see if a change to policy would prevent the proper
> execution of a given exploit. However something like towel root used a
> futex vulnerability, their is no selinux controls on futex usage, so its
> very exploit dependent.
>
> You could, as an additional safeguard, use some type of higher privilege
> mode of execution (think trustzone or hypervisor) to protect various kernel
> pages like the cred and selinux structures in memory, so even the kernel
> has to trap to you to write these pages. The techniques to do this are
> highly architecture specific.
> On Nov 27, 2015 5:42 AM, "심현용" <jonesn5...@gmail.com> wrote:
>
>> Dear all.
>>
>> Thank you for your always kindly explain.
>> I have some question about rooting app 'kingroot'
>>
>> You can install apk bellow site.
>> http://www.kingroot.net/
>>
>> It can root device though supolicy.
>> I think It use to policy-inject, It will change setenforce 0 (permissive
>> mode)
>> and will change permissive per domain like init, init_shell, toolbox,
>> etc...
>>
>> How can I prevent this apk's tool.
>> Is it any method to fix?
>>
>> Please help me..
>>
>> Thanks.
>>
>>
>> _______________________________________________
>> 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.
