The principle of least privilege states that every program and every user of the system should operate using the least set of privileges necessary to complete the job [Saltzer 1974, Saltzer 1975]. The Build Security In website [DHS 2006] provides additional definitions of this principle. Executing with minimal privileges mitigates against exploitation in case a vulnerability is discovered in the code.
Noncompliant Code Example
Privileged operations are often required in a program, though the program might not need to retain the special privileges. For instance, a network program may require superuser privileges to capture raw network packets but may not require the same set of privileges for carrying out other tasks such as packet analysis. Dropping or elevating privileges alternately according to program requirements is a good design strategy. Moreover, assigning only the required privileges limits the window of exposure for any privilege escalation exploit to succeed.
Consider a custom service that must bind to a well-known port (below 1024). To prevent malicious entities from hijacking client connections, the kernel imposes a condition so that only the superuser can use the
bind() system call to bind to these ports.
This noncompliant code example is configured as setuid-superuser. It calls
bind() and later forks out a child to perform the bookkeeping tasks. The program continues to run with superuser privileges even after the
bind() operation is completed.
If a vulnerability is exploited in the main body of the program that allows an attacker to execute arbitrary code, this malicious code will run with elevated privileges.
The program must follow the principle of least privilege while carefully separating the binding and bookkeeping tasks. To minimize the chance of a flaw in the program from compromising the superuser-level account, it should drop superuser privileges as soon as the privileged operations are completed. In the following code, privileges are permanently dropped as soon as the
bind() operation is carried out. The code also ensures privileges may not be regained after being permanently dropped, as in POS37-C. Ensure that privilege relinquishment is successful.
Failure to follow the principle of least privilege may allow exploits to execute with elevated privileges.
CVE-2009-2031 results from a violation of this recommendation. OpenSolaris, in smbfs snv_84 through snv_110, sets permissions based on mount-point options and not actual user information (obtained from the
getgid() functions). An attacker can exploit this to achieve higher permissions. Also, in a certain initialization mode, the code grants read, write, and execute permissions to users other than the owner, which can be exploited to make files world readable [xorl 2009].
|ISO/IEC TR 24772||Adherence to Least Privilege [XYN]|
|MITRE CWE||CWE-250, Execution with unnecessary privileges|
CWE-272, Least privilege violation
|[DHS 2006]||Least Privilege|
|[Wheeler 2003]||Section 7.4, "Minimize Privileges"|
|[xorl 2009]||"OpenSolaris CIFS/SMB Invalid File Flags"|