On 7/3/2023 5:28 PM, Roberto Sassu wrote: > On Mon, 2023-07-03 at 17:06 +0200, Jann Horn wrote: >> On Thu, Jun 22, 2023 at 4:45 PM Roberto Sassu >> <roberto.sassu@xxxxxxxxxxxxxxx> wrote: >>> I wanted to execute some kernel workloads in a fully isolated user >>> space process, started from a binary statically linked with klibc, >>> connected to the kernel only through a pipe. >> >> FWIW, the kernel has some infrastructure for this already, see >> CONFIG_USERMODE_DRIVER and kernel/usermode_driver.c, with a usage >> example in net/bpfilter/. > > Thanks, I actually took that code to make a generic UMD management > library, that can be used by all use cases: > > https://lore.kernel.org/linux-kernel/20230317145240.363908-1-roberto.sassu@xxxxxxxxxxxxxxx/ > >>> I also wanted that, for the root user, tampering with that process is >>> as hard as if the same code runs in kernel space. >> >> I believe that actually making it that hard would probably mean that >> you'd have to ensure that the process doesn't use swap (in other >> words, it would have to run with all memory locked), because root can >> choose where swapped pages are stored. Other than that, if you mark it >> as a kthread so that no ptrace access is allowed, you can probably get >> pretty close. But if you do anything like that, please leave some way >> (like a kernel build config option or such) to enable debugging for >> these processes. > > I didn't think about the swapping part... thanks! > > Ok to enable debugging with a config option. > >> But I'm not convinced that it makes sense to try to draw a security >> boundary between fully-privileged root (with the ability to mount >> things and configure swap and so on) and the kernel - my understanding >> is that some kernel subsystems don't treat root-to-kernel privilege >> escalation issues as security bugs that have to be fixed. > > Yes, that is unfortunately true, and in that case the trustworthy UMD > would not make things worse. On the other hand, on systems where that > separation is defined, the advantage would be to run more exploitable > code in user space, leaving the kernel safe. > > I'm thinking about all the cases where the code had to be included in > the kernel to run at the same privilege level, but would not use any of > the kernel facilities (e.g. parsers). Thanks for reminding me of kexec-tools. The complete image for booting a new kernel was originally prepared in user space. With kernel lockdown, all this code had to move into the kernel, adding a new syscall and lots of complexity to build purgatory code, etc. Yet, this new implementation in the kernel does not offer all features of kexec-tools, so both code bases continue to exist and are happily diverging... > If the boundary is extended to user space, some of these components > could be moved away from the kernel, and the functionality would be the > same without decreasing the security. All right, AFAICS your idea is limited to relatively simple cases for now. I mean, allowing kexec-tools to run in user space is not easily possible when UID 0 is not trusted, because kexec needs to open various files and make various other syscalls, which would require a complex LSM policy. It looks technically possible to write one, but then the big question is if it would be simpler to review and maintain than adding more kexec-tools features to the kernel. Anyway, I can sense a general desire to run less code in the most privileged system environment. Robert's proposal is one of few that go in this direction. What are the alternatives? Petr T
