Security policies

QNX SDP8.0QNX OS System Security GuideAPIConfiguration

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 Process manager 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.

Note:
mkqnximage supports the --secpol and --policy options, which demonstrate how to enable these features.

For more information, see the Security Policies chapter.

Page updated: