Getting MS Applications Right for Your Customers the First Time

You’re proud of the custom application you wrote for your big client. Not only does the software do everything they asked for—with a little extra panache—but you’ve thoroughly tested it on your development environment and you know it’s rock solid. However, when you sit down at the user workstation to show off the software, your brand-spanking-new application crashes spectacularly. Oh, dear. How did that happen?

One strong possibility is that the end user doesn’t have the right privileges to run the application. Most software developers and VARs create their applications with administrator-level rights to network and system resources, but—with an eye toward security—plenty of user accounts have very limited access. It’s a good idea to “develop for the least privileges,” suggests Scott Golightly, senior principal consultant at Keene Inc. and a presenter at Tech Ed this week. Your programming staff is advised to create their applications without running an administrator account, to ensure that the application is given the right security levels.

There’s several good reasons to do so. One obvious advantage is improved security. While some IT “managers” might suggest that it’s easiest to give all users admin privileges, that’s obviously opening the barn door wide. Applications that run with a least-privileges philosophy have a reduced attack surface. “If you don’t have registry access,” points out Golightly, “you can’t mess it up.”

From a VAR’s point of view, a prominent reason is a business issue. Since users are rarely administrators, when you deploy your custom application on their computers they’ll discover that they can’t use features or access resources your application depends on. The client’s IT managers may claim that end-user accounts have no restrictions. Don’t depend on that claim. A failed rollout looks bad, especially when the client was anxiously awaiting deployment, and it sends you back to the drawing board to figure out the problem. And just when you thought you could send the invoice, too.

In addition, if you’re programming in Windows, the “Designed for Windows” logo requires that an application work acceptably—that is, it won’t crash— in non-administrator mode.

Writing your applications for non-admin privileges isn’t always easy, though. It’s more than just booting to a non-admin account and starting up your development suite. You’ll find that you really do need higher-level security access for certain things. For example, non-administrators can’t manage network cards and can’t write to every place in the registry.

However, writing the application with a non-admin account will point out to you—rather dramatically—what those services are, so you can add them as necessary or test for their presence gracefully. In both Windows applications and Web applications, suggests Golightly, your code should explicitly demand the permissions needed, take appropriate actions when the permissions are unavailable, and create custom CAS policies as necessary. There’s plenty of technical details to contend with—which we’ll leave to another time—not the least of which is that you cannot debug processes on non-privileged accounts that are not owned by you, such as SQL Server or Microsoft Message Queue. But the main point from this presentation is a philosophical one: Deal with the issues in advance so your user doesn’t encounter a system failure at the worst possible time.