On 2020/06/25 21:07, Greg KH wrote: >>>> call_usermodehelper() can teach LSM modules via pre-existing file's pathname and >>>> inode's security label at security_bprm_creds_for_exec()/security_bprm_check() etc. >>>> But since fork_usermode_blob() accepts only "byte array" and "length of byte array" >>>> arguments, I'm not sure whether LSM modules can obtain information needed for >>>> inspection. How does fork_usermode_blob() tell that information? >>> >>> It would seem that the "security context" for those would be the same as >>> anything created before userspace launches today, right? You handle >>> that ok, and this should be just the same. >> >> I don't think so. Today when call_usermodehelper() is called, LSMs switch their security >> context (at least TOMOYO does it) for further syscalls from the usermode process started >> by the kernel context. But when fork_usermode_blob() is called, how LSMs can switch their >> security context for further syscalls from the usermode process started by the kernel >> context? > > Ok, that makes a bit more sense. Why not just do the same thing that > you do today with call_usermodehelper()? The logic in a way is the > same, right? > call_usermodehelper() provides information like "the kernel is about to run /sbin/modprobe in order to load foo module" but fork_usermode_blob() does not provide information like "the kernel is about to run a blob that we think is a userspace USB IR filter driver". That is unfriendly to LSM modules. > >>> Right now I, as a kernel module, can read/write to any file in the >>> system, and do all sorts of other fun things. You can't mediate that >>> today from a LSM, and this is just one other example of this. >> >> Some functions (e.g. kernel_sock_shutdown()) bypass permission checks by LSMs >> comes from a sort of trustness that the byte array kept inside kernel address >> space remains secure/intact. > > And what is going to change that "trustness" here? The byte array came > from the kernel address space to start with. Are you thinking something > outside of the kernel will then tamper with those bytes to do something > else with them? Right. e.g. ptrace() will allow reading/writing those bytes to do something else with them. I guess 'gdb -p' is the same meaning. > If so, shouldn't you be preventing that userspace > program that does the tampering from doing that in the first place with > the LSM running? SELinux can handle process isolation very well. But the reality is that none of customers I'm working for can afford using SELinux because SELinux is too complicated to support. Instead, they use proprietary antivirus kernel modules (which tamper with syscall tables and/or security_hook_heads). Therefore, I wish that isolation between processes running fork_usermode_blob() and processes running normal usermode programs is implemented by built-in mechanism (like DAC), and I said We might need to invent built-in "protected userspace" because existing "unprotected userspace" is not trustworthy enough to run kernel modules. That's not just inventing fork_usermode_blob(). at https://lkml.kernel.org/r/62859212-df69-b913-c1e0-cd2e358d1adf@xxxxxxxxxxxxxxxxxxx . I'm happy if we can implement such isolation without counting on in-tree LSMs.
