On 6/24/2020 12:05 AM, Tetsuo Handa wrote:

Forwarding to LSM-ML again. Any comments?

Hey, BPF folks - you *really* need to do better about keeping the LSM
community in the loop when you're discussing LSM issues. 

On 2020/06/24 15:39, Alexei Starovoitov wrote:

quoted

On Wed, Jun 24, 2020 at 01:58:33PM +0900, Tetsuo Handa wrote:

quoted

On 2020/06/24 13:00, Alexei Starovoitov wrote:

quoted

quoted

However, regarding usermode_blob, although the byte array (which contains code / data)
might be initially loaded from the kernel space (which is protected), that byte array
is no longer protected (e.g. SIGKILL, strace()) when executed because they are placed
in the user address space. Thus, LSM modules (including pathname based security) want
to control how that byte array can behave.

It's privileged memory regardless. root can poke into kernel or any process memory.

LSM is there to restrict processes running as "root".

hmm. do you really mean that it's possible for an LSM to restrict CAP_SYS_ADMIN effectively?

I think that SELinux works hard to do just that. SELinux implements it's own
privilege model that is tangential to the capabilities model.

More directly, it is simple to create a security module to provide finer privilege
granularity than capabilities. I have one lurking in a source tree, and I would
be surprised if it's the only one waiting for the next round of LSM stacking.

quoted

LSM can certainly provide extra level of foolproof-ness against accidental
mistakes, but it's not a security boundary.

Gasp! Them's fight'n words. How do you justify such an outrageous claim?

quoted

quoted

Your "root can poke into kernel or any process memory." response is out of step with the times.

Initial byte array used for usermode blob might be protected because of "part of .rodata or
.init.rodata of kernel module", but that byte array after started in userspace is no longer
protected. 

I don't trust such byte array as "part of kernel module", and I'm asking you how
such byte array does not interfere (or be interfered by) the rest of the system.

Could you please explain the attack vector that you see in such scenario?
How elf binaries embedded in the kernel modules different from pid 1?
If anything can peek into their memory the system is compromised.
Say, there are no user blobs in kernel modules. How pid 1 memory is different
from all the JITed images? How is it different for all memory regions shared
between kernel and user processes?
I see an opportunity for an LSM to provide a protection against non-security
bugs when system is running trusted apps, but not when arbitrary code can
execute under root.