Thursday, May 27, 2004 12:54 AM
RHurlbut
Principle of least privilege
Anil has a great summary of an article by David Wheeler on the principle of least privilege. I am listing some of the main points below.
The examples in the article are *nix/Linux focused but the concepts are relevant whatever OS you are running.
"One of the most important ways to secure programs, in spite of these bugs, is to minimize privileges. A privilege is simply permission to do something that not everyone is allowed to do. On a UNIX-like system, having the privileges of the "root" user, of another user, or being a member of a group are some of the most common kinds of privileges. Some systems let you give privileges to read or write a specific file. But no matter what, to minimize privileges:
- Give a privilege to only the parts of the program needing it
- Grant only the specific privileges that part absolutely requires
- Limit the time those privileges are active or can be activated to the absolute minimum
These are really goals, not hard absolutes. Your infrastructure (such as your operating system or virtual machine) may not make this easy to do precisely, or the effort to do it precisely may be so complicated that you'll introduce more bugs trying to do it precisely. But the closer you get to these goals, the less likely it will be that bugs will cause a security problem. Even if a bug causes a security problem, the problems it causes are likely to be less severe. And if you can ensure that only a tiny part of the program has special privileges, you can spend a lot of extra time making sure that one part resists attacks."
This topic is particularly relevant to me this week, partly because of my upcoming WinDev talk on this very subject. I have also been helping a Microsoft Research project that asks these questions: Why is the administrative privilege necessary in a Windows user's daily activities? What can be done to identify unnecessary dependencies on the Administrator privilege?
What I have seen is software that promotes these dependencies do so primarily in one or both of these ways:
1. Registry updates that require administrator privileges
2. File updates in areas that require administrator privileges
The key, I believe, rests in the developer. Most developers run as Administrators on their machines, and typically never notice these problems/issues while developing and testing. By learning to run as non-Administrators, like the users, they could find these issues and solve these problems much quicker.
One "complaint" I hear, of course, is that the tools themselves force developers to run as Administrators, but I have seen better tools coming out that no longer have this requirement. Even if they do, there are ways to work around this to continue to be productive.
More to follow ...
Filed under: .NET, Security