Skip Navigation Links | |
Exit Print View | |
![]() |
Developer's Guide to Oracle Solaris Security Oracle Solaris 10 8/11 Information Library |
1. Oracle Solaris Security for Developers (Overview)
2. Developing Privileged Applications
How Administrators Assign Privileges
How Privileges Are Implemented
setppriv(): for Setting Privileges
priv_str_to_set() for Mapping Privileges
Privilege Bracketing in the Superuser Model
Privilege Bracketing in the Least Privilege Model
Guidelines for Developing Privileged Applications
3. Writing PAM Applications and Services
4. Writing Applications That Use GSS-API
7. Writing Applications That Use SASL
8. Introduction to the Oracle Solaris Cryptographic Framework
9. Writing User-Level Cryptographic Applications and Providers
10. Using the Smart Card Framework
A. Sample C-Based GSS-API Programs
D. Source Code for SASL Example
A privilege is a discrete right that is granted to a process to perform an operation that would otherwise be prohibited by theOracle Solaris OS. Most programs do not use privileges, because a program typically operates within the bounds of the system security policy.
Privileges are assigned by an administrator. Privileges are enabled according to the design of the program. At login or when a profile shell is entered, the administrator's privilege assignments apply to any commands that are executed in the shell. When an application is run, privileges are turned on or turned off programmatically. If a new program is started by using the exec(1) command, that program can potentially use all of the parent process's inheritable privileges. However, that program cannot add any new privileges.
System administrators are responsible for assigning privileges to commands. For more information about privilege assignment, see Privileges (Overview) in System Administration Guide: Security Services.
Every process has four sets of privileges that determine whether a process can use a particular privilege:
Permitted privilege set
Inheritable privilege set
Limit privilege set
Effective privilege set
All privileges that a process can ever potentially use must be included in the permitted set. Conversely, any privilege that is never to be used should be excluded from the permitted set for that program.
When a process is started, that process inherits the permitted privilege set from the parent process. Typically at login or from a new profile shell, all privileges are included in the initial set of permitted privileges. The privileges in this set are specified by the administrator. Each child process can remove privileges from the permitted set, but the child cannot add other privileges to the permitted set. As a security precaution, you should remove those privileges from the permitted set that the program never uses. In this way, a program can be protected from using an incorrectly assigned or inherited privilege.
Privileges that are removed from the permitted set are automatically removed from the effective set.
At login or from a new profile shell, the inheritable set contains the privileges that have been specified by the administrator. These inheritable privileges can potentially be passed on to child processes after an exec(1) call. A process should remove any unnecessary privileges to prevent these privileges from passing on to a child process. Often the permitted and inheritable sets are the same. However, there can be cases where a privilege is taken out of the inheritable set, but that privilege remains in the permitted set.
The limit set enables a developer to control which privileges a process can exercise or pass on to child processes. A child process and the descendant processes can only obtain privileges that are in the limit set. When a setuid(0) function is executed, the limit set determines the privileges that the application is permitted to use. The limit set is enforced at exec(1) time. Removal of privileges from the limit set does not affect any other sets until the exec(1) is performed.
The privileges that a process can actually use are in the process's effective set. At the start of a program, the effective set is equal to the permitted set. Afterwards, the effective set is either a subset of or is equal to the permitted set.
A good practice is to reduce the effective set to the set of basic privileges. The basic privilege set, which contains the core privileges, is described in Privilege Categories. Remove completely any privileges that are not needed in the program. Toggle off any basic privileges until that privilege is needed. For example, the file_dac_read privilege, enables all files to be read. A program can have multiple routines for reading files. The program turns off all privileges initially and turns on file_dac_read, for appropriate reading routines. The developer thus ensures that the program cannot exercise the file_dac_read privilege for the wrong reading routines. This practice is called privilege bracketing. Privilege bracketing is demonstrated in Privilege Coding Example.
To accommodate legacy applications, the implementation of privileges works with both the superuser and privilege models. This accommodation is achieved through use of the PRIV_AWARE flag, which indicates that a program works with privileges. The PRIV_AWARE flag is handled automatically by the operating system.
Consider a child process that is not aware of privileges. The PRIV_AWARE flag for that process would be false. Any privileges that have been inherited from the parent process are available in the permitted and effective sets. If the child sets a UID to 0, the process's effective and permitted sets are restricted to those privileges in the limit set. The child process does not gain full superuser powers. Thus, the limit set of a privilege-aware process restricts the superuser privileges of any non-privilege-aware child processes. If the child process modifies any privilege set, then the PRIV_AWARE flag is set to true.
Privileges are logically grouped on the basis of the scope of the privilege, as follows:
Basic privileges – The core privileges that are needed for minimal operation. The basic privileges are as follows:
PRIV_FILE_LINK_ANY – Allows a process to create hard links to files that are owned by a UID other than the process's effective UID.
PRIV_PROC_FORK – Allows a process to call fork(), fork1(), or vfork().
PRIV_PROC_SESSION – Allows a process to send signals or trace processes outside its session.
PRIV_PROC_INFO – Allows a process to examine the status of processes outside of those processes to which the inquiring process can send signals. Without this privilege, processes that cannot be seen in /proc cannot be examined.
In general, the basic privileges should be assigned as a set rather than individually. This approach ensures that any basic privileges that are released in an update to the Oracle Solaris OS will be included in the assignment. On the other hand, a privilege that is known not to be needed by a program should be explicitly turned off. For example, the proc_exec privilege should be turned off if the program is not intended to exec(1) sub-processes.
File system privileges.
See the privileges(5) man page for a complete list of the Solaris privileges with descriptions.
Note - Solaris provides the zones facility, which lets an administrator set up isolated environments for running applications. See zones(5). Since a process in a zone is prevented from monitoring or interfering with other activity in the system outside of that zone, any privileges on that process are limited to the zone as well. However, if needed, the PRIV_PROC_ZONE privilege can be applied to processes in the global zone that need privileges to operate in non-global zones.