Security policies

This section on Screen security policies is intended for system integrators who are responsible for implementing and enforcing security policies that create and maintain a trusted execution environment.

System integrators use QNX Neutrino security policies to define rules and grant procmgr abilities (abilities) to Screen utilities and applications as they would other processes in the system. For information on securing your system and in general, how to apply security policies to processes, see the System Security Guide . You can apply these policies when you start Screen utilities and applications.

When your system is using security policies, the DRM (Direct Rendering Manager) and Screen services each have two security policies: one that provides a set of abilities that are required for initialization, and a second that provides a set of abilities that are required only during runtime operations. Typically, processes that use the QNX Neutrino security policies transition to a runtime policy when they are finished their initialization—without requiring any additional action on part of the system integrator.

However, DRM (Direct Rendering Manager) and Screen services require deliberate action on the part of the system integrator—mainly due to deferred initializations.

DRM services

The DRM services include the following utilities:

drm-intel
drm-vmwgfx

DRM services include GPU drivers that run in a process separate from Screen. These services may defer initializations to some point in the future that isn't predetermined. Therefore, the transition to their runtime security policy must be done as an intervention by the system integrator at a precise point in time that's not part of the startup sequence; you must use a specific interface to trigger this transition at the appropriate time.

The transition is triggered by writing the string: “secpol_transition” to /dev/secpol/drm. It's expected that a script with a system integration role or a privileged application would execute this command to trigger the transition at a time deemed optimal by the system integrator. You must be running as root, or have the same permissions as the user or group as drm-intel to be able to successfully write the “secpol_transition” string.

For example, assuming the appropriate security types and generated policies are in place, your system startup may include something similar to this:

root:    # on -u qnxuser -T drm_t drm-intel

Then, at the time determined by the system integrator, write the “secpol_transition” string to the /dev/secpol/drm file. For example:

qnxuser: # echo -n secpol_transition > /dev/secpol/drm

This command immediately transitions the DRM services to drop abilities.

When to trigger the runtime security policy transition

Obviously the point in time when you choose to trigger the transition is crucial because you may risk experiencing undesirable outcomes. If you transition before the DRM services have fully completed its initializations:

during the security policy generation, then you risk that the the runtime policy may allow more privileges than is required by the services
during normal usage, then a security and/or permission exception may occur at some point during use, which is likely to force the DRM services to exit

As a system integrator, you may require extensive verification to determine the optimal transition point for your system. You must minimize the risk of race-conditions between dropping a process's ability to perform certain operations and the use of those abilities for initialization.

To determine when the optimal time for you to transition to the runtime security policy for the DRM services in your system, you should consider:

GPU hardware: Anticipate all the GPU hardware features that your system will use. Many hardware feature initializations are deferred until a feature is used. Therefore, the point to initiate the transition to the runtime policy should occur only after the system has fully completed its startup, which may include initializations of all GPU features.
Steady-state operation of your system: Perform the transition only after the system has rendered a few frames of normal operation.
Abilities that are required at steady-state operation of your system: You may observe a permission issue sometime during normal system operation if any ability that's used repeatedly during steady state is missed while generating the runtime policy.
Abilities that are required during initialization: DRM services may fail if abilities that are used at least once during intialization are dropped because you transition before the services are fully initialized. In this case, you'll need to regenerate the security policy and ensure that the feature that exercises the ability is fully initialized before transitioning.

Screen services

Screen services (screen) may defer initialization of its components based on settings in the graphics configuration file. However, unlike DRM services, a system integrator can force Screen to complete its deferred initializations and then transition to its runtime security policy.

The transition is triggered by writing the string: “drop_abilities” to /dev/screen/command. It's expected that a script with a system integration role or a privileged application would execute this command to trigger the transition at a time determined by the system integrator. You must be running as root, or have the same permissions as the user or group as screen to be able to successfully write the “drop_abilities” string.

For example, assuming the appropriate security types and generated policies are in place, your system startup may include something similar to this:

root: # on -u 0:1000 -T screen_t screen -U qnxuser -c /usr/lib/graphics/intel-drm/beebox.conf

Then, at the time determined by the system integrator, write the “drop_abilities” string to /dev/screen/command. For example:

qnxuser: # echo -n drop_abilities > /dev/screen/command

When you're working within a system that applies security policies, this command does the following:

Forces Screen to complete any deferred initializations
Transition Screen to its runtime policy (drop certain abilities)
Switch to a general (non-root) user if specified; note that you must start screen as a root user

If Screen has already fully completed its initalizations (deferred or not) when you execute this command, then it has no effect because Screen always attempts to drop certain abilities (regardless of whether it's running in a system that uses security policies or not).

When to trigger the runtime security policy transition

To determine when to transition to the runtime security policy for the Screen services in your system, you should consider the following configuration parameters:

By default, Screen defers creating a framebuffer until one is required for composition and initializing the blitter module until an execution of a blit operation (e.g., screen_blit() is called and blits are flushed).

Both of these deferral optimize Screen's bootup time. You can set the defer-framebuffer-creation and blit-defer parameters to false in your graphics configuration file to prevent these deferrals.

In the case when screen runs with these deferred initializations, the system integrator can write the “drop_abilities” string to complete these deferrals before dropping abilities. Choosing when to do so is determined by the system integrator based on your system.

In a system that doesn't apply security policies, you must start screen as root. Writing the “drop_abilities” string to /dev/screen/command in this type of system simply makes Screen complete any deferred initialization and switch to a non-root user (i.e., the user that's specified with the -u of screen). Certain root abilities are dropped when switching to run as a non-root user. If you don't specify the -u option, then screen continues running as root—no abilities are dropped and writing the “drop_abilities” string to /dev/screen/command has no effect.