On 8 May 2018 at 00:55, Stephen Smalley <s...@tycho.nsa.gov> wrote:

> On 05/07/2018 12:51 PM, Stephen Smalley wrote:
> > On 05/07/2018 12:30 PM, Yongqin Liu wrote:
> >>     I run the commands as root with userdebug build, after run su
> command.
> >
> > Can you run id -Z before and after running su?  I'm trying to understand
> why the scontext is u:r:kernel:s0 instead of e.g. u:r:shell:s0 (regular
> shell) or u:r:su:s0 (su shell).

h01:04:28 liuyq: ~$ adb shell
hikey:/ $ id
uid=2000(shell) gid=2000(shell)
groups=2000(shell),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid)
context=u:r:shell:s0
hikey:/ $ su
hikey:/ # id
uid=0(root) gid=0(root)
groups=0(root),1004(input),1007(log),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats),3009(readproc),3011(uhid)
context=u:r:su:s0
hikey:/ # ^D
hikey:/ $ ^D
01:05:52 liuyq: ~$ adb shell
hikey:/ $
hikey:/ $ id -Z
context=u:r:shell:s0
hikey:/ $ su
hikey:/ # id -Z
context=u:r:su:s0
hikey:/ #



> Is it because it is a console rather than adb and there is no domain
> transition defined for shell execution from the console?  Should there be a
> domain_auto_trans(kernel, shell_exec, shell) rule in policy?
>
> Both running it from the serial console after su, or the via vts with adb
shell(after adb root), will report kernel scontext domain.


Actually, we don't allow kernel domain to execute anything other than init,
> so I don't understand how you got a shell running in kernel domain (if that
> is in fact what you did).
>

it's what i want to be clear too.

Thanks,
Yongqin Liu

>
> >
> >>
> >>
> >>         It makes sense that you would need read and write permissions
> to the underlying storage.  I am a little puzzled
> >>         as to why it is showing up as a denial on a scontext of
> u:r:kernel:s0 unless your console shell is running in
> >>         the kernel's context.
> >>
> >>         I don't know what changed in the kernel but it seems correct
> that it is now making these checks.  Possibly
> >>         this was part of the changes to support mounting of filesystems
> from user namespaces, to ensure that the
> >>         process was truly authorized to read/write the underlying
> storage.
> >>
> >>
> >>     I think I found the change, it the change here:
> >>     https://android.googlesource.com/kernel/hikey-linaro/+/
> abbb65899aecfc97bda64b6816d1e501754cfe1f%5E%21/#F3 <
> https://android.googlesource.com/kernel/hikey-linaro/+/
> abbb65899aecfc97bda64b6816d1e501754cfe1f%5E%21/#F3>
> >>
> >>     In the change, it calls do_iter_write in vfs_iter_write, and that
> makes the vfs_iter_write call rw_verify_area in directly,
> >>     https://android.googlesource.com/kernel/hikey-linaro/+/
> android-hikey-linaro-4.14/fs/read_write.c#938 <
> https://android.googlesource.com/kernel/hikey-linaro/+/
> android-hikey-linaro-4.14/fs/read_write.c#938>
> >>
> >>     which calls security_file_permission for permission check.
> >>
> >>     While the 4.9 vfs_iter_write does not security_file_permission in
> it's implementation here:
> >>     https://android.googlesource.com/kernel/hikey-linaro/+/
> android-hikey-linaro-4.9/fs/read_write.c <https://android.googlesource.
> com/kernel/hikey-linaro/+/android-hikey-linaro-4.9/fs/read_write.c>
> >>
> >>     I do not verify my thought with any build yet, but I think if I
> reverted the above change for 4.14 kernel, then the denials will go.
> >>
> >> Verified with the change https://android.googlesource.
> com/kernel/hikey-linaro/+/abbb65899aecfc97bda64b6816d1e5
> 01754cfe1f%5E%21/#F3 reverted,
> >> and no similar avc denials reported again. And the original failed VTS
> test cases passed now.
> >>
> >> Need to check on how to update the sepolicy rules on userspace side.
> >
> > Just make sure you wrap it with userdebug_or_eng() so it doesn't get
> included in user builds.
> >
>
>


-- 
Best Regards,
Yongqin Liu
---------------------------------------------------------------
#mailing list
linaro-andr...@lists.linaro.org <linaro-...@lists.linaro.org>
http://lists.linaro.org/mailman/listinfo/linaro-android

Reply via email to