This section provides the following suggestions for developing privileged applications:
Use an isolated system. Youshould never debug privileged applications on a production system. An incomplete privileged application can compromise security.
Set IDs properly. The callingprocess needs theproc_setid privilege in its effectiveset to change its user ID, group ID, or supplemental group ID.
Use privilege bracketing. Whenan application uses privilege, system security policy is being overridden.Privileged tasks should be bracketed and carefully controlled to ensure thatsensitive information is not compromised. SeePrivilege Coding Example for information about how to bracket privileges.
Start with the basic privileges. Thebasic privileges are necessary for minimal operation. A privileged applicationshould start with the basic set. The application should then subtract andadd 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, forexample, PRIV_FILE_DAC_READ.
The daemon switches to the daemon UID.
Avoidshell escapes. The new process in a shell escape can use any ofthe privileges in the parent process's inheritable set. An end user can thereforepotentially violate trust through a shell escape. For example, some mail applicationsmight interpret the!command line as a command and wouldrun that line. An end user could thus create a script to take advantageof any mail application privileges. The removal of unnecessary shell escapesis a good practice.