By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree to receive emails regarding relevant products and special offers from TechTarget and its partners. You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

to allow Unix sudo-like functionality to non-administrative users. It allows for simple privilege escalation, which means you can easily run programs with administrator privileges in Windows. And sudowin is an adjunct to, rather than a substitute for, many existing accreditation technologies in Windows -- including Windows Vista's own User Account Control (UAC), which has been described in some circles as a version of sudo for Windows.

In a way, this description isn't completely accurate, both because of what sudo is and the way Windows works. So, for the sake of explaining sudowin properly, I'll take a moment to describe sudo in detail.

In Unix, the sudo command allows you to launch a process as an administrator, provided you can supply administrative credentials (i.e., an admin password). This allows a user to normally run in a non-elevated context, but elevate privileges on processes that need it.

Secure network folders demand secure permissions

In Windows Vista, the RUNAS command and now UAC, allow something similar to be accomplished, but in a different fashion. When you use these features to run something as an admin, the command in question is run from an entirely different user identity -- one that has administrative privileges. This is why, for instance, if you run a desktop application in Vista that can run without UAC privileges, it often doesn't interact properly with other desktop applications that are running through UAC, simply because they're not running in the same userspace. This is not fatal, but it can be annoying, and it often forces the user to elevate multiple applications at once.

When faced with the way privilege escalation works in Windows, programmer Schley Andrew Kutz decided to "take the road less travelled," as he put it, and create something that functions more like sudo in Windows. The result was named sudowin, appropriately enough, and has been designed to allow extremely granular control over how privileges can be escalated on a per-user and per-application basis. Programs that run through sudowin are not run in separate user contexts, so they can interact with each other conventionally.

An .MSI package installs sudowin, which allows it to be delivered through conventional Windows software distribution mechanisms and makes it part of a system image if needed. Once installed, it's configured in two steps:

The administrator adds any users that will have sudo privileges to a specially created user group.

The administrator then configures an .XML file that controls the way the users' sudo privileges work. This step involves the most work, although the number of settings that need to be changed in the .XML file just to get things running is relatively small. It's only when you're doing more granular or large-scale deployments that it can become labor-intensive.

Each user can have a "whitelist" of applications that they're allowed to run in elevated mode or they can simply be allowed to elevate any application, period. The allowed applications are set in the main .XML configuration file. Credentials can be cached for a period of time, as they are in conventional Unix implementations of sudo. Finally, the program has a plug-in architecture to allow extensions to its functionality (the credential-caching function is one such plug-in), and supports features like only allowing sudo to run between certain times of day.

The biggest drawback right now is the difficulty of configuring the system for many users at once, since everything is done in .XML files. But at its core, this is an extremely promising way to extend on Windows's existing security mechanisms.