Using security policy types

Controlling processes using types

Processes started from the ifs start-up script are not automatically fully controlled by a security policy. Although they appear to have a type ID of 0 and are affected by some parts of a policy, they only have the set of abilities that QNX OS assigns by default.

During the startup process, transient commands such as mount can be run without explicit types but anything that runs beyond startup should not. To start processes with explicit types, QNX OS provides the on utility and slm service, though you can also do it via custom services or utilities by using secpol_posix_spawnattr_settypeid() with posix_spawn().

After a process is started with an explicit type, it is fully controlled by a security policy and any child processes that it creates inherit the parent's type (unless the process explicitly changes it or the policy dictates that the type should change). Thus, by making sure that all processes that run past startup have an explicit type, you ensure that the system is fully controlled by the policy, and only processes that the policy fully controls can be created.

To verify that there are no processes running without an explicit type, run pidin -f a_n after startup and check the output to make sure that all processes have a security type.

Assigning types to objects

Currently, the only object that QNX OS provides that can be given a type is a channel. The type assigned to a channel determines the types that other processes must have to connect to it.

By default, channels have the type of the process that creates them. In addition, a security policy can specify which type a channel takes when a process of a specified type calls resmgr_attach() for a specific path. For more information, see Rules for connecting to channels.

You can add objects that take types as required by defining the object class and the associated actions in the security policy and then referencing them in policy rules. For an example of using a custom class, see Permission checking by operation and object acted on in Customizing permissions using a security policy.

Functions that change a process's type

Processes can change their own type by calling secpol_transition_type() and set the type of processes they spawn by using secpol_posixattr_settypeid(). However, the ability to change their own type or that of their children is controlled by the settypeid ability and, thus, controlled by the policy.

Use the settypeid ability to:

• control the ability of a process to specify a type identifier when a new process is spawned
• indicate that a process is allowed to change its own type

Type names and numbering

Type names follow the same rules as C identifiers. They can contain alphanumeric characters and the underscore, but must not start with a digit.

All the types that the system requires have to be declared in the policy. Undeclared type names (including mistyped names) are detected as errors at compilation time.

When you compile a policy, the types in the policy are assigned an integer value that is an alternate way to identify a security type. Numbering starts at 0 and increases by one for each type that’s declared.

Specifying types in code

To set the type ID using a name, either for itself or when spawning a child process, processes should use APIs such as secpol_posix_spawnattr_settypeid() and secpol_transition_type(). In addition to being easier to use, these functions have the following advantages compared to looking up types and using the type ID directly:

• They make it easier to create code that works both when security policies are in use and when they're not.
• They can use the process's current type and the name they pass in (derived types). This is helpful because, in most cases, the choice of type name should be the responsibility of the system integrator, not an individual process.