Sudowin: One Answer to the Struggle Between Security and Usability

On any given day, I guarantee that a sysadmin is fighting the battle between protecting a company's assets and maintaining usability. Most folks will argue that you can't have both. I will always counter that you can; security and usability are not mutually exclusive. That's not to say that it's easy. Without a doubt, striking the right balance can be difficult in the face of company culture, policy, and the technology itself. But given a fair mix of review, design, and most importantly, patience, it's an attainable goal.

I've always longed for Windows equivalents to many Unix utilities that I use, one of them being the excellent 'sudo' (a full treatment of sudo is beyond the scope of this post so I'd encourage readers to research the utility further for more information). I've seen several attempts to implement sudo or sudo-like functionality for Windows but I never found anything that _was_ sudo. I gave up looking for a while.

Recently, I had a need to revisit the subject and found, among many options, sudowin. It's a slick implementation of sudo available for Windows systems and so far has not disappointed. The project provides an MSI file for easy installation as well as the source code for the curious hacker. The project site (on Sourceforge) doesn't provide documentation, but the folks at SANS have posted a PDF version of the help file.

The current version is 0.4.2-r208 and was released on 9/30/2008. Written in C#, the program installs itself as a service that monitors calls to the sudo command. By default, the service verifies that the user is part of the local 'sudoers' group before checking that the user is authorized to execute the target command/program. Authorized users and commands can be configured in the 'sudoers.xml' file beneath the project's program directory (C:\Program Files\Sudowin). One caveat: the current version of sudowin does not yet support resolving group membership for either local groups or Active Directory groups. You must explicitly define _each_ user that is authorized via the local PC's 'sudoers' group. This does not scale well in large environments, but again, it's open source so feel free to contribute.

The documentation provides great guidance on the configuration file, so I won't go into great detail. However, I will suggest some guidelines:

• Set the top-level value 'allowAllCommands' to "false". A "default deny" policy is the safest bet.
  
• Make use of the block to group sets of commands for groups of users. It will help organize your configuration file.
  
• For all values, note the 'argumentString' and 'md5sum' attributes. Use these to further restrict execution of commands to prevent crafty users from implementing workarounds to sudowin.
  
• Test. Test. Test. Verify that your configuration works before rolling it out to your users. There's nothing more frustrating (to you _and_ the users) than dealing with something that doesn't work (especially when those users had elevated privileges before).
  

So far, I've had great luck with sudowin and the users I've deployed it to are able to do the work they always have done. Despite some minor annoyances such as a very short password cache time and some quirks with how some commands handle arguments (not sudowin's problem), this solution works well. I continue to test its application in other scenarios and am finding it to be very useful. If anyone has used sudowin and would like to provide feedback, feel free to do so (especially if you know how to increase that pesky password cache time period).