Guidelines for Developing Privileged Applications

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.

  1. The daemon starts up as root.

  2. The daemon turns on the basic privilege set.

  3. The daemon turns off any basic privileges that are unnecessary, for example, PRIV_FILE_LINK_ANY.

  4. The daemon adds any other privileges that are needed, for example, PRIV_FILE_DAC_READ.

  5. 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.