Re: [RFC][PATCH] net/bpfilter: Remove this broken and apparently unmantained

[Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>]

On 2020/06/12 8:31, Alexei Starovoitov wrote:
> On Wed, Jun 10, 2020 at 04:12:29PM -0500, Eric W. Biederman wrote:
>> We probably also need to have a conversation about why this
>> functionality is a better choice that using a compiled in initramfs,
>> such as can be had by setting CONFIG_INITRAMFS_SOURCE.

I agree. CONFIG_INITRAMFS_SOURCE or call_usermodehelper() should be fine.

>> Even with this write up and the conversations so far I don't understand
>> what problem fork_usermode_blob is supposed to be solving.  Is there
>> anything kernel version dependent about bpf_lsm?  For me the primary
>> justification of something like fork_usermode_blob is something that is
>> for all practical purposes a kernel module but it just happens to run in
>> usermode.
> 
> that's what it is. It's a kernel module that runs in user space.
> 

How can the code running in the userspace memory be protected? Like you said

  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!

, the userspace memory can be easily interfered from userspace. The kernel module
running in kernel space is protected (unless methods like /dev/{mem,kmem} are used)
but the kernel module running in user space is not protected.

You said

  What you're saying is tomoyo doesn't trust kernel modules that are built-in
  as part of vmlinux and doesn't trust vmlinux build.

but the word 'trust' has multiple aspects. One of aspects is "can the program
contain malicious code?" which would be mitigated by cryptographic signing
technology. But another aspect is "does the program contain vulnerability or
bugs?" which would be mitigated by updating programs as soon as possible.
Yet another aspect is "is the program protected from interference?" which would
be mitigated by enforcing sandbox like seccomp. But to enforce it, we need
information for identifying what does the code need to do.

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().



>> Strictly speaking I am also aware of the issue that the kernel has to
>> use set_fs(KERNEL_DS) to allow argv and envp to exist in kernel space
>> instead of userspace.  That needs to be fixed as well, but for all
>> kernel uses of exec.  So any work fixing fork_usermode_blob can ignore
>> that issue.
> 
> well, this is the problem of usermodehelper_exec.
> usermode_blob doesn't use argv/envp.
> They could be NULL for all practical purpose.
> 

That's what TOMOYO LSM does not like. You said

  tomoyo does path name resolution as a string and using that for security?
  I'm looking at tomoyo_realpath*() and tomoyo_pathcmp(). Ouch.
  Path based security is anti pattern of security.

but, like Casey mentioned, pathnames/argv/envp etc. represents *user intentions*
for controlling what that code can do.

A method for allow anonymously running arbitrary code in userspace memory (which
can be interfered) is so painful. I won't be able to trust kernel modules running
in userspace memory.