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 Screen services and DRM (Direct Rendering Manager) 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, both Screen services and DRM (Direct Rendering Manager) require deliberate action on the part of the system integrator—mainly due to deferred initializations.
Screen services
Screen services (screen) may defer initialization of its components based on settings in the graphics configuration file. A system integrator can force screen to complete its deferred initializations and then transition to its runtime security policy. screen does not automatically drop root abilities.
The transition is triggered by writing the string: drop_privileges
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.
For example, assuming the appropriate security types and generated policies are in place, your system startup may include something similar to this:
root: # screen -u 65:65 -c /usr/lib/graphics/<platform>/graphics.conf
Then, at the time determined by the system integrator, write the drop_privileges
string to /dev/screen/command. For example:
root: # echo drop_privileges > /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
- Requests the GPU to drop all its privileges if supported
- Transition screen to its runtime policy
- Switch the process to the requested user
DRM services
- drm-rpi4
- drm-virtio
- drm-vmwgfx
If the DRM server is started by screen, it will inherit screen's security policies and assigned user. screen will request the transition of the DRM server's processes while it transitions, acting as an extension.
If the DRM server is started separately before screen, then the system integrator must trigger the transition
by writing the string: drop_privileges
to /dev/drm/command. If you have specified the -u
user_info, the command will transition the process to the requested user.
For example, assuming the appropriate security types and generated policies are in place, your system startup may include something similar to this:
root: # drm-rpi4 -u 65:65
Then, at the time determined by the system integrator, write the drop_privileges
string to the /dev/drm/command file. For example:
root: # echo drop_privileges > /dev/drm/command