On 8 May 2018 at 12:15, Sandeep Patil <sspa...@google.com> wrote: > > > On Mon, May 7, 2018 at 10:46 AM Stephen Smalley <s...@tycho.nsa.gov> wrote: > >> 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(). > > > ... or simply re-order the events as ... > > 1. create a file > 2. format it with mkfs.extN > 3. .. then assign a loopback device > 4. mount (this used to only generate read access from kernel domain) > > That is what LTP tests have been doing and seems like this particular > one swaps #2 & #3 which causes the 'write' check. We didn't want the kernel > domain to have write access anywhere IIRC, so the policy change is correct. > > Once the filesystem is created and mounted, all reads/writes come > from userspace domain anyway. > > Unless, the problem is with step #4 above and that has now changed with > 4.14. I'll check on my end to see if this is the case .. > > The failed LTP testcases are following:
VtsKernelLtp#fs.fs_fill_64bit VtsKernelLtp#syscalls.fallocate04_64bit VtsKernelLtp#syscalls.fallocate05_64bit VtsKernelLtp#syscalls.fchmod06_64bit VtsKernelLtp#syscalls.fsync01_64bit VtsKernelLtp#syscalls.ftruncate04_64_64bit VtsKernelLtp#syscalls.ftruncate04_64bit VtsKernelLtp#syscalls.link08_64bit VtsKernelLtp#syscalls.linkat02_64bit VtsKernelLtp#syscalls.mkdirat02_64bit VtsKernelLtp#syscalls.mknod07_64bit VtsKernelLtp#syscalls.mknodat02_64bit VtsKernelLtp#syscalls.msync04_64bit VtsKernelLtp#syscalls.rmdir02_64bit VtsKernelLtp#syscalls.setxattr01_64bit VtsKernelLtp#syscalls.mount01_64bit VtsKernelLtp#syscalls.mount02_64bit VtsKernelLtp#syscalls.mount06_64bit VtsKernelLtp#syscalls.umount01_64bit VtsKernelLtp#syscalls.umount02_64bit VtsKernelLtp#syscalls.umount03_64bit VtsKernelLtp#syscalls.umount2_01_64bit VtsKernelLtp#syscalls.umount2_02_64bit VtsKernelLtp#syscalls.umount2_03_64bit VtsKernelLtp#syscalls.utime06_64bit VtsKernelLtp#syscalls.utimes01_64bit -- Best Regards, Yongqin Liu --------------------------------------------------------------- #mailing list linaro-andr...@lists.linaro.org <linaro-...@lists.linaro.org> http://lists.linaro.org/mailman/listinfo/linaro-android
