Sudo/Runas support for PowerShell Crescendo

[theJasonHelmick]

In many cases when working with native commands, a change to the elevation level is required to achieve the expected results on either Linux or Windows systems. As an example, on a linux system the sudo command changes elevation and the results of the native command:

> whoami
> JasonHelmick

> sudo whoami
> Root

We are thinking of how best to support the elevation needs of native commands with PowerShell Crescendo. Below is an example of how this might be written into the json file.

{
"$schema" : "./Microsoft.PowerShell.Crescendo.Schema.json",
"Verb": "Invoke",
"Noun": "whoami",
"OriginalName":"/usr/bin/whoami",
"ElevationCommand": {
"Command": "sudo"
}
}

The json could also would support arguments passed to the elevation command, similar to this:

"ElevationCommand": "command",
"Arguments": [
"arg1",
"arg2"
]

First, would appreciate feedback on handling elevation and the above example.
Also, based on the discussion #45 (PowerShell Crescendo json files should support multiple native commands)

• should we support both linux and Windows elevation in the same json
• if so, what scenarios do you see this addressing?

[gaelcolas]

Glad you reminded me of the discussions tab yesterday, I'm not used to them yet.

As discussed with @JamesWTruher yesterday, it's good to offer this capability at the command level (one can always use noInvocation and handle this on their own if needed).

I think you have a typo in your second example (curly brackets), it should be:

"ElevationCommand": {
    "command": "sudo",
    "Arguments": [
        "arg1",
        "arg2"
    ]
}

To your question:

should we support both linux and Windows elevation in the same json

I'd say yes, probably.
Some commands, say (and this may be a bad example) kubectl or oc can be run the same way on both OSes, so you'd want this supported within 1 definition.

Now I'd just want to share the challenges I hit when looking into this for my PSNativeCmdDevKit module:

Providing Password to Sudo

Some OS (i.e. credativ:Debian:9:latest in Azure) needs to have the password provided when calling sudo, which leads to command like this:

"echo \"<%= ENV['MACHINE_PASS'] %>\" | sudo -S sh -c \"chmod +x /etc/sudoers.d && echo 'azure ALL=(ALL) NOPASSWD: ALL' > /etc/sudoers.d/waagent\""

When you need to pass 2 arguments

That gets 'messy' when you need to pass 2 arguments (say password first, then something else...

{ echo ENV:['PASS'] ; echo 'somethingelse'; } | sudo -c cat

I wonder how often that'd be needed, but good to have that in mind.

Sudo -u

Sometimes we just want to run as a different user like sudo -u otheruser

[P0w3rChi3f]

I would concur with @gaelcolas with running a different user, especially since most security frameworks state admins need two accounts. One user account for most things and an elevated account to perform administration.

If you had to prioritize between creating elevation between Windows and Linux, I would probably go with Linux first. Windows is pretty forgiving and will prompt you when you are logged in as an admin, Linux not so much. The user you are logged in with may have sudo rights but you will have to invoke them anytime you need elevated rights.