Skip Navigation Links | |
Exit Print View | |
![]() |
Developer's Guide to Oracle Solaris Security Oracle Solaris 11 Express 11/10 |
1. Oracle Solaris Security for Developers (Overview)
2. Developing Privileged Applications
How Administrators Assign Privileges
How Privileges Are Implemented
Compatibility Between the Superuser and Privilege Models
setppriv(): for Setting Privileges
priv_str_to_set() for Mapping Privileges
Privilege Bracketing in the Superuser Model
Privilege Bracketing in the Least Privilege Model
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. Introduction to the Oracle Solaris Key Management Framework
A. Sample C-Based GSS-API Programs
D. Source Code for SASL Example
This section provides the following suggestions for developing privileged applications:
Use an isolated system. You should never debug privileged applications on a production system, as an incomplete privileged application can compromise security.
Set IDs properly. The calling process needs the proc_setid privilege in its effective set to change its user ID, group ID, or supplemental group ID.
Use privilege bracketing. When an application uses privilege, system security policy is being overridden. Privileged tasks should be bracketed and carefully controlled to ensure that sensitive information is not compromised. See Privilege Coding Example for information on how to bracket privileges.
Start with the basic privileges. The basic privileges are necessary for minimal operation. A privileged application should start with the basic set. The application should then subtract and add privileges appropriately.
A typical start-up scenario follows.
The daemon starts up as root.
The daemon turns on the basic privilege set.
The daemon turns off any basic privileges that are unnecessary, for example, PRIV_FILE_LINK_ANY.
The daemon adds any other privileges that are needed, for example, PRIV_FILE_DAC_READ.
The daemon switches to the daemon UID.
Avoid shell escapes. The new process in a shell escape can use any of the privileges in the parent process's inheritable set. An end user can therefore potentially violate trust through a shell escape. For example, some mail applications might interpret the !command line as a command and would execute that line. An end user could thus create a script to take advantage of any mail application privileges. The removal of unnecessary shell escapes is a good practice.