With the help of Run as and Sudo for Windows, you can run applications that require elevation and administrator rights. Learn about the differences between these solutions to elevate apps.
Contents of this article

In general, do you operate your Windows client computers by using a standard user account or an administrative account? Least-privilege security states that you should operate your computers using a standard user account. Remember that if malware compromises your system, the rogue process can hijack the currently logged-on user's credential and privilege context. Not cool.

Therefore, the goal is to run as a standard user habitually and elevate your credential only for processes that require such elevation.

Today we will review some of the options available in Windows for applying least-privilege security during our daily computer operations. Information security is, above all, a balancing act between security assurance on one side and user convenience on the other.

Run as ^

Microsoft gave us User Account Control (UAC) in Windows Vista. The idea is you operate the computer using a standard user context (typically with a user account that's a member of the system's local Users group) and elevate to administrative privilege only when necessary.

From the Windows GUI, we access Run as by right-clicking an application or script icon (or shortcut) and selecting Run as administrator. As you can see in the following screenshot, File Explorer displays a UAC shield to denote any action that requires administrative elevation, while Start menu icons do not.

Note: Programmers can insert a flag in their source code to require administrative elevation for their process to execute. The process icon should then display in File Explorer with the UAC shield.

Accessing Run as from the Windows desktop

Accessing Run as from the Windows desktop

In any event, if you've logged onto the computer as a standard user, you'll need to provide another administrative credential to complete this action, as shown in the next screenshot:

Providing administrative credentials via UAC

Providing administrative credentials via UAC

Note: Shift + right-clicking a program shortcut from File Explorer gives you the Run as different user option, which is handy in certain circumstances.

As you probably know, we can access Run as and User Account Control from the command line as well. For instance, the following statement starts Visual Studio Code (VSCode) under another credential:

runas /user:zo "C:\Program Files\Microsoft VS Code\Code.exe"

Notes:

The good news is that Run as works. The bad news is that whenever you start a process with Run as, you start that process under a totally different credential. This can have more ramifications than you think.

Take a look at the next screenshot. I am logged into my Windows 10 workstation with my standard Tim user account. Next, I started VSCode by using Run as administrator and authenticating as a local administrator named Zo.

Sadly, any user-specific references (such as the $profile automatic variable) will reference Zo and not Tim.

Context switching with User Account Control

Context switching with User Account Control

Let's take a look at the best free solution I could find to provide administrative elevation without the annoying account context switching.

Sudo for Windows ^

Sudo (pronounced sue-doo or SUH-doo) is an old Unix/Linux tool that enforces least-privilege code execution in an elegant way. Andrew Kutz developed Sudo for Windows as a way to give administrators sudo capability from the Windows desktop and command line.

Sudo for Windows is free, open-source software. Mr. Kutz hasn't updated the software for quite a few years, but it works well so far on my Windows 10 workstations. If I were a developer, here is what I would do (maybe you can do this if you're so inclined?):

  • Fork the project from SourceForge to GitHub
  • Digitally sign the executable
  • Ensure compatibility with both Active Directory domain and local user accounts

Here is how Sudo for Windows works: The software creates a service named Sudowin that operates with Local System privilege. It also creates a local group called Sudoers. Populate the Sudoers local group with user accounts that should be able to access Sudo for Windows. I show you a "mash-up" of these steps in the next screenshot.

Configuring Sudo for Windows

Configuring Sudo for Windows

To use Sudo for Windows graphically, right-click the process or script icon and select Sudo... from the shortcut menu. You then supply your own user account password, as shown in the next screen shot.

Using Sudo from the Windows desktop

Using Sudo from the Windows desktop

As a test, I started three instances of Notepad:

  • One instance using my Tim standard user credential
  • One instance using Sudo for Windows and the Tim account password
  • One instance using Run as administrator and authenticating as Zo

I used Process Explorer to view metadata. First, look at the next screenshot and observe what's going on:

Comparing process identity in Process Explorer

Comparing process identity in Process Explorer

  • Process ID (PID) 6920: Notepad running under my Tim standard account with medium (non-elevated) process integrity
  • PID 7484: Notepad running as Zo with high (elevated) integrity
  • PID 824: Notepad running elevated with my Tim account

Process Explorer gives you additional details when you right-click the process, select Properties, and navigate to the Security tab.

Standard user at left and Sudo elevated user at right

Standard user at left and Sudo elevated user at right

Sadly, I have found Sudo for Windows to be a bit inconsistent when launched from the command line. For instance, typing sudo code from the Run box asked for my current user password, but it never launched VSCode.

On the other hand, from a non-elevated PowerShell console, typing sudo control opened the Control Panel under elevated context on my system.

Open Control Panel with Sudo from the command line

Open Control Panel with Sudo from the command line

Wrap-up ^

For me, it was the uptick in ransomware attacks that finally convinced me to run as a standard user instead of as an administrator on all my client workstations. Here's what I suggest you do on your administrative workstations:

Subscribe to 4sysops newsletter!

  • Rename the built-in Administrator and Guest accounts, give them strong passwords, and then disable them
  • Create a separate local administrator account and give it a strong password for Run as elevation
  • Convert your current user account to a standard user and ensure that user ID is a member of the Sudoers group
avatar
0 Comments

Leave a reply

Please enclose code in pre tags

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2021

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account