The principle of least privilege was originally defined by Saltzer (1975):

Every program and every user of the system should operate using the least set of privileges necessary to complete the job. Primarily, this principle limits the damage that can result from an accident or error. It also reduces the number of potential interactions among privileged programs to the minimum for correct operation, so that unintentional, unwanted, or improper uses of privilege are less likely to occur. . .

I sometimes like to think about this principle in reverse. Imagine if you ignore it entirely and run all your code with full privileges all the time. You've basically turned off a whole raft of security features provided by your platform. The less privilege you grant to a program, the more walls are erected around that program by the platform. If a program misbehaves because of a coding error, perhaps one that was tickled by a malicious user providing malformed input (WhatIsSecureCode), you'll be glad those walls are in place.

Security compromises usually occur in stages: The attacker gains a certain level of privilege via one security hole and then tries to elevate his privilege level by finding another hole. If you run programs with more privilege than they really need, the attacker's life is much easier.

This principle can be applied in many different places; it really is a mindset that you should follow as you design and build systems. The following paragraphs describe some examples that are relevant to .NET programmers working on Windows. The examples are by no means exhaustive, but they will give you some concrete ideas that will help you get into the right mindset.

Daemon processes on servers should be designed and configured to run with only the privileges they need to get the job done. This means that you should absolutely avoid the SYSTEM account when configuring the ASP.NET worker process, Windows Services, COM+ servers, and so on (HowToChooseAnIdentityForADaemon).

Desktop applications should be designed to conform to the Windows Logo guidelines¹ to ensure that they don't attempt to write to protected parts of the file system or registry. When you ship programs that don't follow these guidelines, they break when users attempt to run with least privilege (under normal, nonadministrative user accounts). If you don't want your Mom browsing the Web as an administrator, then start writing programs that she can use as a normal user (WhatIsANonPrivilegedUser)!

When opening files or other secure resources, open them only for the permissions you need for that session. If you plan on reading a file, open it for read-only permissions. Don't open it for read-write permissions thinking, "Someday I may want to write to that file." Open resources for the permission you need at that particular moment.

Use the least privileged form of state management you can for your application. In the .NET Framework, storing application state via Isolated Storage requires less privilege than using a named file, and it has the added benefit of ensuring that your data is written to the user profile (WhatIsAUserProfile), which is one of the Windows Logo guidelines I alluded to earlier.

Close references to files and other resources as soon as possible. This is especially important if you use impersonation (WhatIsImpersonation), as these resources can "leak" from one security context (WhatIsSecurityContext) to the next if you're not careful. Remember that Windows and the .NET Framework tend to check permissions only when resources are first opened. This is a performance enhancement, but it can also lead to security holes if you don't close those resources promptly when you're finsished using them.

And, finally, choose to run with least privilege whenever you log in to your computer, whether you're at home or at work. HowToDevelopCodeAsANonAdmin provides tips for software developers trying to run with least privilege.

¹ http://www.microsoft.com/winlogo

PortedBy LucaMauri