On 2020/06/10 9:05, Alexei Starovoitov wrote:
> I think you're still missing that usermode_blob is completely fs-less.
> It doesn't need any fs to work.
fork_usermode_blob() allows usage like fork_usermode_blob("#!/bin/sh").
A problem for LSMs is not "It doesn't need any fs to work." but "It can access any fs and
it can issue arbitrary syscalls.".
LSM modules switch their security context upon execve(), based on available information like
"What is the !AT_SYMLINK_NOFOLLOW pathname for the requested program passed to execve()?",
"What is the AT_SYMLINK_NOFOLLOW pathname for the requested program passed to execve()?",
"What are argv[]/envp[] for the requested program passed to execve()?", "What is the inode's
security context passed to execve()?" etc. And file-less execve() request (a.k.a.
fork_usermode_blob()) makes pathname information (which pathname-based LSMs depend on)
unavailable.
Since fork_usermode_blob() can execute arbitrary code in userspace, fork_usermode_blob() can
allow execution of e.g. statically linked HTTP server and statically linked DBMS server, without
giving LSM modules a chance to understand the intent of individual file-less execve() request.
If many different statically linked programs were executed via fork_usermode_blob(), how LSM
modules can determine whether a syscall from a file-less process should be permitted/denied?
By the way, TOMOYO LSM wants to know meaningful AT_SYMLINK_NOFOLLOW pathname and !AT_SYMLINK_NOFOLLOW
pathname, and currently there is no API for allow obtaining both pathnames atomically. But that is a
different problem, for what this mail thread is discussing would be whether we can avoid file-less
execve() request (i.e. get rid of fork_usermode_blob()).
