Living the "Least Privilege" Lifestyle, Part 5: Surviving as a Mere Developer
- Visual Studio .NET
- Coping During Development
- Storing Stuff
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
In part 4 of this series, I attacked the common wisdom that a developer has to have administrative rights on the local machine, the entire domain, and every piece of server software on the network in order to write code. Okay, it's not that extreme, but it's a rare developer who needs any kind of administrative rights to write code. After all, the typical developer spends most of the day attending meetings and the rest of the time editing text files. Neither of those activities requires administrative privileges, except maybe to get into the executive liquor closet to make all the meetings more enjoyable.
That isn't to say that developers don't need special permissions sometimes. Debugging a process one owns doesn't require special permissions; anyone can do that. But debugging other processes, such as when writing server code—ASP.NET applications, for example—does require special permissions. If the application has a legitimate need to access protected resources, such as to configure a device in the HKEY_LOCAL_MACHINE hive of the registry, you have to have the permission. But granting administrative privileges so that a developer has one or two additional permissions is a horribly insecure practice, for all of the reasons I've written about in this series.
In this fifth and final edition of the "Living the Least Privilege Lifestyle" series, I'm going to cover some tips and tricks for surviving as a mere, non-administrative developer. Most of this discussion will be focused on development using Visual Studio .NET 1.0 and 2003, but much applies to general Windows and other operating systems development.
Visual Studio .NET
Because some kinds of development activities require additional privileges, the Visual Studio (VS) installation package automatically adds a couple of Windows groups to the local machine: Debugger Users and VS Developers. The VS Developers group is for web developers, since they have to interact with Internet Information Server (IIS) to create and configure virtual directories. IIS is server software, so higher permissions are required. If an ASP.NET developer is not a member of this group, she'll have to have some other way of interacting with IIS. Keep in mind that by being a member of this group, a hacker who gets control of the user account can make all the same changes to IIS, potentially a dangerous power to have. But you shouldn't be doing development work on a production server anyway! By the way, Visual Studio 2005 has its own web server that it controls, so this group is no longer required.
The other group, Debugger Users, is potentially much more dangerous. Debugging processes that you don't own requires a very high privilege level, so if you're not developing server applications you probably don't need membership in this group. If you need to debug applications, consider having a different login to perform common computer tasks—surfing the web, reading email, writing memos—and another to use when developing software. It's unfortunate that the VS installation package assigns the current user to Debugger Users by default, since that practice potentially opens so many security problems. Ironically, it doesn't even include one permission you'll commonly need—SeDebuggerPrivilege. This is a powerful privilege, so it may be best to just Run As these processes as an administrator.
These comments just scratch the surface of the issues of developing software with VS under a least-privilege user account (LUA), but Microsoft has a nice whitepaper on MSDN that covers all of the ins and outs, with step-by-step procedures for making it work: "Developing Software in Visual Studio .NET with Non-Administrative Privileges" by Lars Bergstrom of the VS Core Team.