Privilege control

For best security, after system startup, all services should be running with their own unique user and group IDs.

This practice has several benefits:

• It makes it much easier to take advantage of POSIX permissions to control access to resources such as files and other resource managers.
• Security tests are, in some cases, stricter when two processes do not share a user ID than when they do.

Running resource managers with non-root user IDs requires privileges that are usually only available to user ID 0, root. There are two ways to grant these privileges to resource managers not running as root:

After system startup, you can check that all processes are non-root by using the pidin utility. You can also use pidin to verify that they have not retained the setuid ability, which would permit them to revert to root.

Within the kernel and process manager, control over a process's ability to perform many actions is governed not by the user ID (UID) of the process, but by a set of approximately 70 permissions called process manager (procmgr) abilities.

For detailed information on using procmgr abilities, go to the Abilities chapter. For a list of abilities, go to the Abilities Reference chapter.

Security policies provide a central way to control the privileges that processes have, which simplifies an audit of a system’s security.

Much of the information is in one place rather than widely distributed and (usually) hidden within individual resource managers. Resource managers are also often ill-placed to make system-level security decisions and the developers of them are frequently more concerned with the component's functionality than with security.

The following privileges can be controlled with security policies:

• procmgr abilities (see Abilities)
• locations in path space where resource managers can use resmgr_attach() to attach their channels
• the resource managers that a process is allowed to communicate with
• other custom privileges as defined by individual resource managers
• protection against execution of untrusted code via the pathtrust feature (see Pathtrust)

Security policies are required to control all but procmgr abilities. For procmgr abilities, using security policies usually provides an easier and more accurate way of assigning abilities. While using security policies requires the determination of the rules that should govern each process, secpolgenerate allows most of this work to be automated and supports the incremental generation of policies as needed over a long development cycle and for multiple versions of a product.

Using secpolgenerate also provides an easy solution to the biggest problem with working on a system using security policies: a system that is properly secured, is, and should be, very difficult to develop on. The sorts of operations a developer might want to do are similar in many respects to what an attacker might do. Developing on such a system is likely inefficient and not very pleasant. A system that is well suited to development is very different from the one that is ready for release. However, having a development system that is too different from the released system causes other problems. Using secpolgenerate, you can make development and release systems that are identical except for a small amount of startup code that is used at the very beginning of the boot process. Done properly, a development system can behave identically to a released one, with the added ability of allowing a developer to edit a configuration file and reboot to remove either all or selected constraints.

For more information, see the Security Policies chapter.