Privilege Escalation Prevention in Practice
The Escalator Is Out of Order
So, we must realize that some processes are simply going to need higher privilege levels than others in order for our information systems to operate and be useful. Further, we realize that users and applications should be given the minimum privilege they need in order to do what they need to do. This limits the ability of users to access data they shouldn’t. Further, if they do repurpose an application in order to access restricted information, if that application has the least privilege possible, we limit the possible abuse. What are some of the means we can use to accomplish this?
What Now?
Here are a few techniques to restrict the potential for privilege escalation:
Chroot daemons when possible - On Unix-based systems applications can be run “chrooted”. This restricts the file system space visible to the application by changing the apparent root directory for that application. This can greatly restrict the potential for abuse.
Run services as unprivileged accounts - This is one of the most basic, but is often overlooked. On Windows, the service you design does not need to run as Local System simply because it is a service. Learn what rights the service actually needs and use an otherwise restricted account that has been granted those rights.
Use bounds checkers and stress tests when debugging - Many privilege escalations take place when applications crash. Some applications will simply need more privileges in order to do anything useful, so we should test them thoroughly and debug them as best we can to limit the potential for buffer overruns and crashes to provide a vector for privilege escalation.
Require multi-factor authentication & authorization - For large multi-user systems, with disparate data repositories and applications, a multitude of user sessions are running concurrently. Consider in your architecture requiring more than simply a single authentication step to access data. Escalating privilege of one step in the process will buy them nothing if additional validation is required.
Conclusions
Experts have noted that it may not be possible to eliminate the risk of users obtaining elevated privileges. The nature of multi-user modern operating systems may require agents and actors that can be subverted to unintended purposes. Even otherwise perfect code may have an unforeseen possible consequence allowing for malice to bypass sound and otherwise secure preparations. We likely reach a point of diminishing returns in our efforts to prevent any possible privilege escalation or alteration. The foundations and best practices for securing user access to data should be kept in mind when designing, developing, integrating, and administering new mulit-user systems. As the lines blur more and more between systems, data locations, and what data is and is not public, the issues become more complex.
This post is part of the series: The Principle of Least Privilege
This article series explains the Information Security and Computer Science concept of the principle of least privilege. We examine what privileges are, why they are an important concept in multi-user systems, and why this principle is a sound security concept. See examples and means of prevention.
