IT Manager's Journal

The concept of least privilege was first defined in 1975 in a paper entitled "The Protection of Information in Computer Systems" by Jerome Saltzer and Michael Schroeder. On the user level, a simple example of least privilege is the practice of creating everyday accounts for regular computing, and a root account that has full access to the system. Average users do not need to alter system files or settings, so their accounts do not allow it. Furthermore, the most common policy is for the administrator to log in as root only for as long as needed to run a specific task. In some distributions, such as Ubuntu, the use of sudo assures that only the designated processes or programs are run as root, and for as short a time as possible.

On a more sophisticated level, least privilege encourages the creation of multiple administration accounts. Wreski gives the example of an Apache web server configured to run each basic process in its own account, and explains it this way: "Let's say that an administrator's password is compromised and the attacker tries to run an exploit through Apache to read the email server. With the least privilege concept, a company can have a layered defense to cut off the attack by ensuring that Apache does only what it is told to do, and no more. The access given by the admin's account doesn't help the attacker, because it won't even let the software run this attacker's exploit. The exploit then gets 'jailed' and the threat is stopped."

In theory, Wreski continues, least privilege is the most important of the basic security principles. Applying it requires careful planning to define all the tasks that will be done on a system, who will do them, and what is enough to secure the system.

In practice, however, the effectiveness of least privilege by itself is undermined in two ways. First, "it's a very broad principle," Wreski says, "And the term 'least' is subjective, especially in a corporation with multiple stakeholders and different needs." For example, from a system administrator's viewpoint, the syncing of a laptop with a user's network account is a security nightmare, yet the convenience of the operation for ordinary users generally means that it is allowed.

Second, Wreski says, "Needs can change and evolve in some of the best cases, and be completely wrong in some of the worst." In other words, starting off with a secure system is not enough; an ongoing policy is needed to prevent spur of the moment decisions from weakening it.

For both these reasons, Wreski says, the more "granular security" is built into a system, the more successful the application of least privilege is likely to be. "Broad layers of global network security will not always be enough," he says. Instead, what is needed is "the ability to lock-down individual processes and applications."

Yet implementing this ability can be a problem in itself. Wreski says, "The issue is making it easy enough to implement, where the need for security doesn't take a bit out of productivity. Locking down every process or application is of course not realistic. But you can design very effective boundaries within some of your most dangerous applications, especially those outer-network channels" -- that is, those which interact with other systems.

"You might not enforce least privilege over single process for all applications," Wreski continues, "but, depending on use, you can increase overall security dramatically."

Proprietary and free software implementations

The trouble is, such considerations are rarely implemented in commercial proprietary software. "Least privilege," Wreski says, "is a kind of security that implies that there could be a need to reduce the damage once a breach happens." This possibility is alarming to most companies, who would prefer not to consider the possibility that someone could break into their systems in the first place. For this reason, marketers of commercial security solutions prefer to emphasize keeping intruders out.

Wreski bluntly describes this emphasis as "FUD-oriented," He comments, "You can do an amazingly effective job to limit access from foreign sources before they ever reach the corporate network. But what if a phishing attack succeeds or a previous employee gains access? Sure, it's easy and marketable to say this will never happen but, the truth is, there's the possibility. If you had the choice, would you prefer software that is pro-actively addressing this possibility in their code or one that has their head in the sand and thinks the castle will be forever fortified?"

By contrast, Wreski cites free software programs such asSELinux as an example of software that incorporates least privilege into its architecture. Available in many distributions, including Red Hat Enterprise Linux and Guardian Digital's own En Garde, SELinux incorporates a system of mandatory access control, in which all files on a system are individually mapped and labelled, thereby enabling administrators to control access to each of them separately, providing the sort of granular control that Wreski endorses.

Furthermore, because the code of applications like SELinux is freely available, users have the added advantage of confirming for themselves that it is implementing the principle of least privilege.

By contrast, Wreski says, "With proprietary systems, it's entirely up to the vendor to determine the need at the process. And certainly, vendors that have experience with implementing least privilege can effectively do this. But with proprietary formats, there isn't really an option. There is no access to developers or a community to address them. There's just a huge thriving community that provides input for open source, and that contributes to better solutions."

Future trends

With the rise of social networking sites and other Web 2.0 applications, Wreski believes that least principle is more important than ever. Such uses, he says "can help to nullify some aspects of network security. User access controls can become meaningless if your secretary gives out the default password, or an employee locks down an application level, not just the user level."

As phishing attacks become increasingly sophisticated and successful, Wreski predicts not only an increased need for the application of least privilege, but increasingly granular application of it as well. As evidence, he points to the current interest in Multilevel Security, which includes the concept of prioritizing access, which he says is "very near to the epitome of least privilege." However, Wreski warns that Multilevel Security "can get very complex, so there will need to be easy ways for an IT professional to customize their policy."

Wreski concludes, "One of the issues here is the combination of creating effective security policies to integrate well. Web server applications have to interact and overlap with email applications which overlap with anti-spam/anti-virus applications. There are many facets to corporate security, and one of the interesting things to watch for in 2008 will be how unified development of platforms and applications takes hold. Simply incorporating least privilege is not the same thing as incorporating it well. Vendors in the space that have experience developing applications and integrating them with a secure platform will be a in a better position to implement least privilege successfully."