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: >> On Wed, Jun 24, 2020 at 01:58:33PM +0900, Tetsuo Handa wrote: >>> On 2020/06/24 13:00, Alexei Starovoitov wrote: >>>>> 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. >> 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? >>> 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. >>
