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? LSM can certainly provide extra level of foolproof-ness against accidental mistakes, but it's not a security boundary. > 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.
