On 2020/06/09 1:23, Alexei Starovoitov wrote: > On Sun, Jun 07, 2020 at 11:31:05AM +0900, Tetsuo Handa wrote: >> On 2020/06/07 10:49, Alexei Starovoitov wrote: >>> So you're right that for most folks user space is the >>> answer. But there are cases where kernel has to have these things before >>> systemd starts. >> >> Why such cases can't use init= kernel command line argument? >> The program specified via init= kernel command line argument can do anything >> before systemd (a.k.a. global init process) starts. >> >> By the way, from the LSM perspective, doing a lot of things before global init >> process starts is not desirable, for access decision can be made only after policy >> is loaded (which is generally when /sbin/init on a device specified via root= >> kernel command line argument becomes ready). Since >> fork_usermode_blob((void *) "#!/bin/true\n", 12, info) is possible, I worry that >> the ability to start userspace code is abused for bypassing dentry/inode-based >> permission checks. > > bpf_lsm is that thing that needs to load and start acting early. > It's somewhat chicken and egg. fork_usermode_blob() will start a process > that will load and apply security policy to all further forks and execs. fork_usermode_blob() would start a process in userspace, but early in the boot stage means that things in the kernel might not be ready to serve for userspace processes (e.g. we can't open a shared library before a filesystem containing that file becomes ready, we can't mount a filesystem before mount point becomes ready, we can't access mount point before a device that contains that directory becomes ready). TOMOYO LSM module uses call_usermodehelper() from tomoyo_load_policy() in order to load and apply security policy. What is so nice with fork_usermode_blob() compared to existing call_usermodehelper(), at the cost of confusing LSM modules by allowing file-less execve() request from fork_usermode_blob() ?
