On 05/07/2018 01:17 PM, Yongqin Liu wrote: > > > On 8 May 2018 at 00:55, Stephen Smalley <s...@tycho.nsa.gov > <mailto: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.
Ok, the implication is that the actual write request is happening from a kernel thread, not in the context of the process that is performing the mkfs command, e.g. the write is deferred to a work queue or similar mechanism. If so, then there isn't much point in performing the check at all, because it will always be from the kernel domain regardless of the userspace originator. I'm not sure that moving the security_file_permission() calls into rw_verify_area() was a good idea since a userspace permissions check is logically different than the other kinds of validation being performed there. However, I think it was motivated by the fact that originally all callers of rw_verify_area() were also performing a security_file_permission() call, and to help ensure that no future read/write interfaces bypassed the security check. The underlying hook function, selinux_file_permission(), only performs a permission check if something has changed since the checks performed at open time, e.g. the current process' sid differs from that of the opener, the inode SID has changed, or the policy has changed. In this case, I assume it is because the writer is running in the kernel domain whereas the opener was in the domain of the process that invoked mkfs, e.g. su. The near term fix is to simply allow it for the kernel domain under userdebug_or_eng(). A longer term fix might be to rework where security_file_permission() is called so that it only occurs when operating in the context of a userspace process, not a kernel thread. The latter would be taken to the linux-security-module and linux-fsdevel mailing lists for consideration.
