I deliberately avoided this, because I feel like this should not be a general concept for accessing Windows APIs. That is a much more dangerous thing to enable, and would require the kernel team to handle calls meant to be exactly the same as Windows calls, which may be difficult (or impossible) in this kind of process.
So I think the naming, and the function call structure, should make it clear that this is not a real Windows process that can call Windows APIs ever. It is a special kind of blank process that can never, ever, under any circumstances call a real Windows API. It can only make a syscall to a special kind of syscall handler that allows a few basic functions, but those functions are specific to this kind of process and are not meant to be completely equivalent to any existing Windows function.
Hopefully that makes some sense... I could write a separate article on this if need be. I think it's very important that this be distinct from "you can call regular Windows APIs from a whitelist", because I think having that ability means that the kernel has to expose a much larger attack surface underneath than if they can just write a very specific, less capable syscall handler for these processes.
The name "CreateUnprivilegedProcess" would be more descriptive. Then you could have "RequestPrivilege" and "RelinquishPrivilege" as other calls.
I deliberately avoided this, because I feel like this should not be a general concept for accessing Windows APIs. That is a much more dangerous thing to enable, and would require the kernel team to handle calls meant to be exactly the same as Windows calls, which may be difficult (or impossible) in this kind of process.
So I think the naming, and the function call structure, should make it clear that this is not a real Windows process that can call Windows APIs ever. It is a special kind of blank process that can never, ever, under any circumstances call a real Windows API. It can only make a syscall to a special kind of syscall handler that allows a few basic functions, but those functions are specific to this kind of process and are not meant to be completely equivalent to any existing Windows function.
Hopefully that makes some sense... I could write a separate article on this if need be. I think it's very important that this be distinct from "you can call regular Windows APIs from a whitelist", because I think having that ability means that the kernel has to expose a much larger attack surface underneath than if they can just write a very specific, less capable syscall handler for these processes.