On Wed, Jun 24, 2020 at 7:16 PM Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > What is unhappy for pathname based LSMs is that fork_usermode_blob() creates > a file with empty filename. I can imagine that somebody would start abusing > fork_usermode_blob() as an interface for starting programs like modprobe, hotplug, > udevd and sshd. When such situation happened, how fork_usermode_blob() provides > information for identifying the intent of such execve() requests? > > fork_usermode_blob() might also be an unhappy behavior for inode based LSMs (like > SELinux and Smack) because it seems that fork_usermode_blob() can't have a chance > to associate appropriate security labels based on the content of the byte array > because files are created on-demand. Is fork_usermode_blob() friendly to inode > based LSMs? No, because we cannot label the inode based on the program's purpose and therefore cannot configure an automatic transition to a suitable security context for the process, unlike call_usermodehelper(). It is important to note that the goal of such transitions is not merely to restrict the program from doing bad things but also to protect the program from untrustworthy inputs, e.g. one can run kmod/modprobe in a domain that can only read from authorized kernel modules, prevent following untrusted symlinks, etc. Further, at present, the implementation creates the inode via shmem_kernel_file_setup(), which is supposed to be for inodes private to the kernel not exposed to userspace (hence marked S_PRIVATE), which I believe in this case will end up leaving the inode unlabeled but still end up firing checks in the bprm hooks on the file inode, thereby potentially yielding denials in SELinux on the exec of unlabeled files. Not exactly what we would want. If users were to switch from using call_usermodehelper() to fork_usermode_blob() we would need them to label the inode in some manner to reflect the program purpose prior to exec. I suppose they could pass in some string key and SELinux could look it up in policy to get a context to use or something. On a different note, will the usermode blob be measured by IMA prior to execution? What ensures that the blob was actually embedded in the kernel image and wasn't just supplied as data through exploitation of a kernel vulnerability or malicious kernel module? Yes, things are already bad at that point but it would be good to be able to detect launch of the malicious userspace payload regardless (kernel exploit can't undo the measurement extended into the TPM even if it tampers with the IMA measurement list in the kernel, nor fake a quote signed by the TPM).
