Security policies

Updated: April 19, 2023

Security policies can make some aspects of security much easier for a developer.

Ideally, no resource manager runs as root. Achieving this goal usually requires the configuration of abilities. Manually configuring process manager (procmgr) abilities on a per-process basis is error-prone.

When security policies are in use, developers can use the API provided by libsecpol instead of manually configuring the specific privileges a process requires. When using libsecpol, developers only need to indicate when the process has completed initialization. Developers can leave it up to the security policy to ensure that processes have the right set of privileges to start up and the right, hopefully smaller, set for continued operation.

When a privileged process must spawn child processes with varying privilege requirements, libsecpol can make this easy without the need for the developer to know what the requirements are. In the case where all child processes can have the same privileges, the use of security policies can allow the common set to be configured without any action by the developer.

Usually, a resource manager handling requests has little to base security decisions on other than if a client opened a resource for reading or writing. The libsecpol API provides a set of functions that can provide more fine-grained checks, which is useful for such things as devctl() calls.

While a resource manager usually must be written to be able to work both when security policies are in use and when they aren’t, when libsecpol is used, it can work under both circumstances without writing code to cover each case. The system is not as secure when security policies are not in use but is still functional.

For more information, see Security Policies.