On 2020/06/25 21:07, Greg KH wrote:

quoted

quoted

quoted

    call_usermodehelper() can teach LSM modules via pre-existing file's pathname and
    inode's security label at security_bprm_creds_for_exec()/security_bprm_check() etc.
    But since fork_usermode_blob() accepts only "byte array" and "length of byte array"
    arguments, I'm not sure whether LSM modules can obtain information needed for
    inspection. How does fork_usermode_blob() tell that information?

It would seem that the "security context" for those would be the same as
anything created before userspace launches today, right?  You handle
that ok, and this should be just the same.

I don't think so. Today when call_usermodehelper() is called, LSMs switch their security
context (at least TOMOYO does it) for further syscalls from the usermode process started
by the kernel context. But when fork_usermode_blob() is called, how LSMs can switch their
security context for further syscalls from the usermode process started by the kernel
context?

Ok, that makes a bit more sense.  Why not just do the same thing that
you do today with call_usermodehelper()?  The logic in a way is the
same, right?

call_usermodehelper() provides information like "the kernel is about to run
/sbin/modprobe in order to load foo module" but fork_usermode_blob() does not
provide information like "the kernel is about to run a blob that we think is
a userspace USB IR filter driver". That is unfriendly to LSM modules.

quoted

quoted

Right now I, as a kernel module, can read/write to any file in the
system, and do all sorts of other fun things.  You can't mediate that
today from a LSM, and this is just one other example of this.

Some functions (e.g. kernel_sock_shutdown()) bypass permission checks by LSMs
comes from a sort of trustness that the byte array kept inside kernel address
space remains secure/intact.

And what is going to change that "trustness" here?  The byte array came
from the kernel address space to start with.  Are you thinking something
outside of the kernel will then tamper with those bytes to do something
else with them?

Right. e.g. ptrace() will allow reading/writing those bytes to do something
else with them. I guess 'gdb -p' is the same meaning.

                 If so, shouldn't you be preventing that userspace
program that does the tampering from doing that in the first place with
the LSM running?

SELinux can handle process isolation very well. But the reality is that none of customers
I'm working for can afford using SELinux because SELinux is too complicated to support.
Instead, they use proprietary antivirus kernel modules (which tamper with syscall tables
and/or security_hook_heads). Therefore, I wish that isolation between processes running
fork_usermode_blob() and processes running normal usermode programs is implemented by
built-in mechanism (like DAC), and I said

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

at https://lkml.kernel.org/r/62859212-df69-b913-c1e0-cd2e358d1adf@i-love.sakura.ne.jp .
I'm happy if we can implement such isolation without counting on in-tree LSMs.