On Tue, Jun 09, 2020 at 02:29:09PM +0900, Tetsuo Handa wrote:
> On 2020/06/09 10:28, Alexei Starovoitov wrote:
> >> 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() ?
> >
> > For the same reason you did commit 0e4ae0e0dec6 ("TOMOYO: Make several options configurable.")
> > Quoting your words from that commit:
> > "To be able to start using enforcing mode from the early stage of boot sequence,
> > this patch adds support for activating access control without calling external
> > policy loader program."
> >
>
> I can't catch what you mean. That commit is to allow not to call usermode helper.
>
> You can't start a usermode helper which requires access to filesystems (e.g. ELF loaders,
> shared libraries) before call_usermodehelper() can start a usermode helper which requires
> access to filesystems. Under such a restricted condition, what is nice with starting a
> usermode helper? Programs which can be started under such condition will be quite limited.
> My question is: why you can't use existing call_usermodehelper() (if you need to call
> a usermode helper) ?
I think the confusion comes from assumption that usermode blob is a dynamic file that
needs ld.so, shared libs and rootfs. This mode is supported by the blob loading
logic, but it's not a primary use case. It's nice to be able to compile
that blob with -g and be able to 'gdb -p' into it. That works and very
convenient when it comes to debugging. Compare that to debugging a kernel module!
It's pretty cool to have vmlinux with kernel module-like feature
that folks can breakpoint and single step while the kernel is running.
That's how we've been developing bpfilter. Sadly the other two patches
(by Davem and Daniel) didn't land:
https://lore.kernel.org/patchwork/patch/902785/
https://lore.kernel.org/patchwork/patch/902783/
and without them bpfilter looks completely useless.
The main mode of bpfilter operation was envisioned as rootfs-less.
It must work with any init= including busybox. For production the bpfilter
user mode blob was compiled as static binary with no dependencies.
So there is no path to point to. It should be ready before pid 1
will do its first iptables sys_setsockopt. If user reboots the kernel
with different init= cmdline the bpfilter should still be doing its job.
Like builtin kernel module.
Anyway bpfilter is only one of the use cases for 'elf in vmlinux'.
I think better name would have been 'user space kernel modules'.
