Start a process as a different user on Unix

[arunjvs]

Background:

Starting processes as different users is one of the most fundamental needed to do several useful things - especially so for automation, script execution and privilege de-escalation in services and sandboxing. This is even more so true on Linux, where you can achieve a lot with just running commands as various users, and where the overall boot process follows the fork, impersonate and exec pattern.

How it works on Windows:

The System.Diagnostics.Process.StartInfo instance member of type System.Diagnostics.ProcessStartInfo takes a username, domain and password for the target process's credentials. The credentials are then used to impersonate as the user (Windows itself implements this through credential providers) and create a new process (Windows succeeds it after local authority checks) in that context.

Problems with current workaround in Linux:

We can currently workaround this by launching another broker process (with set-uid and set-gid bits set) as root and then let it impersonate and exec the target executable into itself. This requires extreme care to implement safely, especially when you want password less authentication because you are already root or satisfy other constraints (see man 2/3 set(e)uid/set(e)gid), and will potentially redo what the "su" command does. Using su itself comes with nuances on how to pass the password string and wait for the process status and defeats the purpose of the language (C#).

Another way is to do a set(e)uid/set(e)gid before the fork() and exec() in Process.Start(). Doing this before the fork() comes with it's own nuances - you cannot use the libc call exposed by Mono.Unix directly (at least always) since it propagates it to all threads, potentially disrupting their I/O. You have to instead do a syscall() and undo it very reliably, and hope that threads don't switch in the meanwhile due to TPL, etc..

Overall there is no clean and reliable solution in Linux that's at par with Windows.

Proposal for Linux:

We need a similar mechanism in Linux, and it can work with the same API conventions as Windows for an explicit username-password based process invocation. However, the full credential specification (see man 7 credential) of a Linux process has more/different identities than an NT process token. At the minimum, we need to support the groupname (gid) of the new process along with the username (uid). So we'll need a ProcessStartInfo.GroupName that defaults to the current group, a ProcessStartInfo.UserName that defaults to the current user.

Implementation outline in Linux:

The presence or default of ProcessStartInfo.Password affects the behaviour:

If it is default (null), then we should try to invoke through a normal set(e)uid() + set(e)guid() and fail if we don't have permission appropriately. This works only for the superuser/same target credential as calling process.

If it is present, then we should do an equivalent of Windows - authenticate with various PAM modules and then launch the process. The "su" program explicitly does this.

The su process also takes care of various checks, order of impersonation, sanitizing the environment as per command line options, whether to invoke a new shell and create a terminal/logon session, etc.. See su.c and su-common.c in https://www.kernel.org/pub/linux/utils/util-linux/v2.31/ for source.

Finally, we can either do a fork(), set(e)gid(), set(e)uid() and exec*() in the managed process for the no password case or have a dotnet in-box broker for PAM authentication.

Related: https://github.com/dotnet/corefx/issues/3187

[arunjvs]

@Petermarcu @eerhardt @stephentoub

api-needs-work
X-Plat
os-linux
area-System.Diagnostics

[danmoseley]

@arjunvs do you want to sketch the new API you envision, to make an API request?

[arunjvs]

The API remains exactly same as it is today, except that:

• The fields ProcesStartInfo .UserName and .Password actually work on Linux.
• We have a new String ProcessStartInfo .GroupName.
• All the three properties are independently optional.

[karelz]

Can you use the formal API proposal form please? It helps us to look at API additions in unified way & we put it on the top of the top post. Thanks!

If it is just one property, it should be easy-ish. The only worry I have is that it is Linux-only property. Not sure if we want to mix them up with current ProcessStartInfo properties -- are any of them Windows-only BTW?

Regarding implementation:
I am not sure how authentication with PAM modules would look like -- naively I would expect just one call into kernel and magic happens. Is that not the case? Do we have to do more? How complicated / error prone is it? Does it differ between distros? Do you have a sketch of the code?

[arunjvs]

I'd like to expand on the other questions before proposing the one field addition API change :)

AFAIK, the following other members of ProcessStartInfo are already either Windows only, or have a different meaning on Linux, or are not uniformly implementable on all distros:

• CreateNoWindow
• LoadUserProfile
• UseShellExecute (Being lazy here. Didn't check. Do we use bash/sh?)
• Verb
• Verbs

So we already have a spill. Maybe we should re-organize into some NT and Linux specific class hierarchy for ProcessStartInfo.

Using PAM is not a single call, nor is it into the kernel. PAM is a user mode library, a manager for various stacks of user authentication, authorization, password and session management. You first interact with a specific PAM stack to exchange credentials, and on success, do what you have to do - in this case assume the target user's identity in your fork()ed child process - setuid() and setgid() - and then do an execve() - these are the calls actually into the kernel. Now the thing is this child process needs to be a set-uid and set-gid binary (AFAIK such a filesystem way is the only way to escalate/impersonate on Linux if you are not root already, or ask a service already running as root, like for ex. ssh) for it to be able to impersonate the user and group after passing PAM's tests. This is how "su" works for example. (Plus you also anyway need to be a privileged user like root/shadow to use PAM modules like /etc/shadow - the local user password database).

Even for the case without password (when you are already root), we may need to ask PAM modules whether the user currently has logon authority (but then again root may do anything in Linux, including changing that policy, but you still want to honour it).

The source code for su that does the above scheme is available in the util-linux project (kernel.org hosts important user-land stuff too) link I mentioned above. su-common.c has most of the code.

Various clients to PAM include the GUI login screens (like GDM), the su command, the sudo command, the passwd command, ssh server, etc.. Dotnet's Process.Start broker process could be another.

While su-common.c would be an ideal target to mimic, here's more documentation on PAM:

• http://www.linux-pam.org/
• http://www.tuxradar.com/content/how-pam-works

[eerhardt]

I'm not convinced we should try to support the Password property on non-Windows. @arunjvs, the approach you outline above concerns me a bit. In order for that approach to work, the dotnet executable needs to have the setuid bit set on it, and basically its owner would have to be root.

This is how su works. Its owner is root and it has the setuid bit set. This mean whenever su is run, it runs as root, which allows it to check other users' passwords, and allows it to start a new process as that user.

Since the dotnet host can execute any arbitrary IL code, it probably isn't a good idea to set the setuid bit on it, as that would mean you could execute any code as the owner of the dotnet executable.

I do agree we can implement UserName, and that we should add a GroupName property. And if the process doesn't have the rights to change the user or group, then you will get an error. That scenario makes sense to me. I'm just not convinced starting a process as another user and programmatically giving the user's password is a common scenario in Unix programs.

[wtgodbe]

@wfurt this is the issue we talked about in the meeting

[wfurt]

I would suggest to implement this proposed part:

If it is default (null), then we should try to invoke through a normal set(e)uid() + set(e)guid() and fail if we don't have permission appropriately. This works only for the superuser/same target credential as calling process.

The path with pam may not be as simple. pam may not even be there (and yes it probably is on main Linux distributions) It would also typically have one configuration entry for each app in /etc/pam.d/
Now, should we expect "dotnet" there, or should that be per published application. With that, the publishing process may not have access there and that may lead to weird failures.

the su path may be workable. However the ProcessStartInfo has no clue about sanitization.
One would expect that variables set should be available to child process and they may not be.
You would still be stuck with some platform differences.

As final note, I feel that de-escalation is more interesting. We should be able to start service and privileged user and drop rights when not needed. That should work even without fork and new process IMHO. That would mimic typical Unix server like Apache.

[arunjvs]

@eerhardt

I'm not convinced we should try to support the Password property on non-Windows.

Agreed. At this point we are not immediately dependent on Password, but maybe in the future because we don't want to run as root. But for now, this is good enough for us.

the dotnet executable needs to have the setuid bit set on it,

Disagree - we should definitely not have setuid on the dotnet executable itself, but it doesn't have to be either. It could be through another broker executable (like su). But then it creates other kinds of problems like how you would install such an executable in the first place without always depending on distro's package system, like for mobile installations, similar to /etc/pam.d/* that @wfurt mentioned.

So if we want to support Password, we either have to wrap around su, have our own broker process with the above problems, or use some other wilder replacement to su, like a loopback SSH, which will be less messy (use a lib instead of process), but takes another bad dependency on an SSH server running.

[wfurt]

on the suid I agree with @arunjvs. Putting suid on dotnet would make any operation with effective admin rights. So for user trickery dotnet needs to be executed with privilege or user can publish executable and fix it there in their separate application packaging. If we rely on the rights, we should document that properly. If we choose to do the password I probably in favor of using su. It is not great as there is really no API but it could work on most cases. For one, it has suid bit already so it can do the uid change trickery.

[arunjvs]

@wfurt

The path with pam may not be as simple. pam may not even be there ... weird failures.

Agree that PAM may not be simple, but following su closely maybe enough. Disagree that PAM may not be there - I know of no distro fully supported by .NET where there is no PAM (unless it's from the bush era). su has completely moved to PAM. Also it is incorrect to interpret that to start process as a different user, we need to use a per application PAM config - here the intent is of "login" or "su" i.e. password based impersonation by dotnet or clr. Applications may themselves have different intents for impersonation, in which case they will pick their own PAM stack and credential exchange mechanism, in which case they will have to have their own config. The end result is that they have an equivalent on a security principal/token, which is a related but separate issue #15177 opened by @Petermarcu. Infact building a managed PAM library will help implement both these needs. But going back, as dotnet itself being the client to the PAM library, our intent here is parallel to su.

the su path ... platform differences.

Sanitizing environment is generally important due to obvious security reasons (we don't need it though) and su has the - argument for it among others. We may match it with ProcessStartInfo .Environment .EnvironmentVariables .LoadUserProfile, .WorkingDirectory.

As final note ... Apache.

De-escalating irreversibly (setuid) within the same process has AFAIK a different use case - acquire a resource only possible as root and immediately become less powerful for the lest of your lifetime - such as grab a TCP port below 1024 (Apache wants port 80). It doesn't directly translate into a privilege separation/sandboxing mechanism that we need - unless we have a cooperating child process that's completely in our control and sets up some IPC with the parent, or branches into a custom fork()==0 path (which is inside CLR BTW) and then then correctly setuid() and execve() another untrusted process. More messier, more unnecessary processes. Doing all that is essentially implementing the title of this thread.

[danmoseley]

dotnet/corefx#26431 makes Process.Start use username on Unix. Seems worth keeping this issue open to continue the discussion about potentially supporting password and elevation (eg via PAM) in future. I would be interested to hear from other customers.