On Mon, Feb 1, 2021 at 9:47 AM Jason A. Donenfeld <Jason@xxxxxxxxx> wrote: > > Hi Andy & others, > > I was reversing some NT stuff recently and marveling over how wild and > crazy things are over in Windows-land. A few things related to process > creation caught my interest: > > - It's possible to create a new process with an *arbitrary parent > process*, which means it'll then inherit various things like handles > and security attributes and tokens from that new parent process. > > - It's possible to create a new process with the memory space handle > of a different process. Consider this on Linux, and you have some > abomination like `forkat(int pidfd)`. My general thought is that this is an excellent idea, but maybe not quite in this form. I do rather like a lot about the NT design, although I have to say that their actual taste in the structures passed into APIs is baroque at best. If we're going to do this, though, can we stay away from fork and and exec entirely? Fork is cute but inefficient, and exec is the source of neverending complexity and bugs in the kernel. But I also think that whole project can be decoupled into two almost-orthogonal pieces: 1. Inserting new processes into unusual places in the process tree. The only part of setuid that really needs kernel help to replace is for the daemon to be able to make its newly-spawned child be a child of the process that called out to the daemon. Christian's pidfd proposal could help here, and there could be a new API that is only a minor tweak to existing fork/exec to fork-and-reparent. 2. A sane process creation API. It would be delightful to be able to create a fully-specified process without forking. This might end up being a fairly complicated project, though -- there are a lot of inherited process properties to be enumerated. (Bonus #3): binfmts are a pretty big attack surface. Having a way to handle all the binfmt magic in userspace might be a nice extension to #2. --Andy
