[Process] Start process as non-elevated user

[adamsitnik]

Today I've been studying some MSFT source code and I got to the conclusion that we most likely need to add the ability to start process as non-elevated user when running as elevated user.

One way of doing that on Windows would be to use following sys-calls:

• https://learn.microsoft.com/en-us/windows/win32/api/winsafer/nf-winsafer-safercreatelevel
• https://learn.microsoft.com/en-us/windows/win32/api/winsafer/nf-winsafer-safercomputetokenfromlevel
• https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessasusera

Any feedback is welcome!

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-diagnostics-process
See info in area-owners.md if you want to be subscribed.

[adamsitnik]

On Unix, we would need to obtain the real uid/gid and also restore the groups:

pid_t pid = fork();
if (pid == 0) {
    // child
    struct passwd* pw = getpwuid(getuid());

    initgroups(pw->pw_name, pw->pw_gid);
    setgid(pw->pw_gid);
    setuid(pw->pw_uid);

    execve(...);
}

[adamsitnik]

cc @jkotas @tmds

[tmds]

On Unix, you can run as a different user through ProcessStartInfo.UserName.

If you elevate through something like sudo, getuid does not return the original user (the original user is available via the SUDO_USER environment variable). getuid would only be useful for +s binaries. Those are typically very minimal, security-sensitive apps.

[jkotas]

I do not think we should be adding this as an API.

I think we should focus on better interop to address these scenarios. There are many ways to launch a process in custom way on Windows. What's required to allow people to launch a process in a custom way using these Safer APIs and still allow them to take advantage of the goodness in the managed process type like the output streaming, etc.?

[huoyaoyuan]

The related use case I've seen is mostly about UAC. Specifically, launch a process (often self) with UAC prompt, and launch non UAC-elevated process from elevated one.

[ZzZombo]

I do not think we should be adding this as an API.

I think we should focus on better interop to address these scenarios. There are many ways to launch a process in custom way on Windows. What's required to allow people to launch a process in a custom way using these Safer APIs and still allow them to take advantage of the goodness in the managed process type like the output streaming, etc.?

I don't think I follow you. This can be said about basically anything because P/Invoke exists.

[jkotas]

Windows exposes many different options for launching new processes. For example, https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute lists 14 different options and it is not a complete list. My estimate is that we can find 30+ options for customizing process launch on Windows. I do not think we want to introduce a first-class managed APIs on System.Diagnostics.Process for all of them.

The problem is that the moment you have a need to use one of the options that are not exposed as a managed API on System.Diagnostics.Process, you have to roll your own implementation from scratch. For example, let's say that I want to launch a process with a custom PROC_THREAD_ATTRIBUTE_SECURITY_CAPABILITIES and consume its output using IAsyncEnumerable<System.Diagnostics.ProcessOutputLine>. How do I do that?

Currently, I have to copy & paste thousands (?) of lines of System.Diagnostics.Process implementation. Can we do better than that? It is what I meant by a better interop.

My preference would be for #94127 to be handled by the "better interop" solution as well.

[adamsitnik]

I do not think we want to introduce a first-class managed APIs on System.Diagnostics.Process for all of them.

I agree that we should not be doing this for all of them, but there are some that are quite frequently implemented by our customers and foremost hard to get right. And in my opinion we should be recognizing such patterns and exposing them as first-class managed APIs. For now I am going to change the milestone to Future and wait for more feedback from our security champions (@GrabYourPitchforks @vcsjones).

[adamsitnik]

Currently, I have to copy & paste thousands (?) of lines of System.Diagnostics.Process implementation. Can we do better than that? It is what I meant by a better interop.

The async implementation is very simple, so it would be less than a hundred lines of code for ReadAllLinesAsync.

But I agree that we need a better interop story and also implement #71595 (I've just set the milestone to 11 to ensure it happens).

My preference would be for #94127 to be handled by the "better interop" solution as well.

We could expose the ability to pass the creation flags (#71515), but in case of CREATE_SUSPENDED we also need to be able the resume the process. And for that I am afraid we have to store the main thread handle.

On Unix, fork+exec always require the users to provide a native library to be able to customize process creation. This is really hard to get right. Right now I see two ways to improve it:

• implement an ability to specify a custom unmanaged delegate (I am sorry I might be using the wrong naming). The downside is that users would still need to ship custom native library with their app. We have discussed it offline in the past.
• implement StartSuspended and Resume and let the users run custom logic for the suspended process. The downside is that the users can use only sys-calls that accept pid to set something:

        using SafeProcessHandle processHandle = SafeProcessHandle.Start(info);

        int pid = processHandle.ProcessId;

        Marshal.SetLastSystemError(0);
        int currentPriority = getpriority(PRIO_PROCESS, (uint)pid);
        Assert.Equal(0, Marshal.GetLastSystemError());

        int result = setpriority(PRIO_PROCESS, (uint)pid, currentPriority + 1);
        Assert.Equal(0, result);

        processHandle.Resume();

[tmds]

To make it more clear: my earlier comment was meant to say that I don't think we should enable/encourage implementing setuid binaries using .NET.

I have no opinion on the Windows side.