Security Features Overview

QNX SDP8.0QNX OS System Security GuideAPIConfiguration

In today's computing environment, security plays a critical role in keeping systems protected against rogue actors. Security needs to be considered at all stages of system design instead of being bolted on at later stages. QNX OS's design and dedicated security features allow it to defend and protect itself against a wide variety of attacks. This guide provides an overview of the security features and where they are applicable to security problems faced by systems. This information will allow system designers and software developers to factor in the security elements of their designs at the appropriate stage.

Process protection

Stack protection

QNX OS supports stack cookies and all stacks are non-executable by default. Stack canaries are enabled in prebuilt QNX OS applications and shared libraries. Stack canaries are checked before function return to make sure they have not been modified (e.g., as a result of a buffer overflow on stack allocated variables). Any modification to the stack canary on the stack will result in process abort.

For the compiler options that enable stack cookies, see Stack protection in Security features for developers.

Heap protection

By default, allocations on the heap are marked non-executable.

The default heap allocation algorithm uses cookies for inline heap allocation data to detect heap corruption.

Process manager abilities

Process manager abilities avoid the danger of having all-powerful root processes. Instead of granting permissions based whether a process has a user ID of 0 or not, the process manager grants permissions based on the abilities assigned to a process. Each ability can be independently granted or denied.

For more information, see Process manager abilities in Security features for system integrators.

Fortified system functions

The C library for QNX OS provides fortified versions of various system functions that check their arguments at compile time, runtime, or both for conditions such as:

  • potential overflow of a destination buffer (if the compiler is able to determine the size of the destination buffer)
  • missing or extra arguments to functions that accept a variable number of arguments

If one of these conditions is detected at compile time, the compiler reports an error. If the condition is detected at runtime, the affected process outputs diagnostic information and then aborts to mitigate potential harm. The runtime checks are designed to have a negligible impact on performance so that fortified system functions can be used in both development and production environments.

The use of fortified system functions is enabled via the _FORTIFY_SOURCE feature test macro you set using the -D_FORTIFY_SOURCE=[1|2] compiler option. For instructions on building components to use fortified system functions, see Fortified system functions in Security features for developers. For instructions for determining whether or not a component has been built to use fortified system functions, see Fortified system functions in Security features for system integrators.

Executable or writable and executable mappings

A process can deny itself the ability to create further executable, or writable and executable, mappings by dropping abilities after startup. This behavior can limit the potential for an attacker to exploit a process by injecting executable code into it.

For more information, see procmgr_ability() in the C Library Reference.

Process resource limits (POSIX rlimits)

One approach to reduce the impact of system-wide Denial of Service (DoS) attacks is by using resource limits. QNX OS supports setting limits on CPU use, memory use, open connections, and other system resources.

For more information, see prlimit() in the C Library Reference.

RELRO (Relocation Read-Only)

If you enable Relocation Read-Only (RELRO) when you compile a program, the compiler can mark the relocation sections of an executable as read-only after the dynamic loader has finished loading and linking an executable.

For information on the compiler options that enable full or partial RELRO, see RELRO in Security features for developers.

Pathtrust

QNX OS can restrict the code executed by a privileged process using a mechanism called pathtrust. In the event that a privileged process is compromised, an attacker cannot further compromise the system by redirecting execution to the attacker’s code that is persisted somewhere on the system. Pathtrust uses QNX Trusted Disk and abilities for enforcement.

For more information, see Pathtrust.

System protection

Secure boot

Secure boot from a root of trust is supported. Secure boot relies on support by the SoC being used.

For more information, see Secure boot in Security features for system integrators.

Address space layout randomization

Address space layout randomization varies the location of data and instructions each time an executable is loaded. This decreases the likelihood that attackers will be able to develop working exploits to any vulnerabilities found.

For more information, see Address space layout randomization (ASLR) in Security features for developers and Address space layout randomization (ASLR) in Security features for system integrators.

Access control

The POSIX permissions model as well as access control lists (ACLs) are supported.

For more information, see Access control in Security features for system integrators.

Security policies

Security policies allow centralized control of process privileges and avoid the need to make difficult security decisions in the processes themselves.

For more information, see Security policies in Security features for system integrators.

QNX Trusted Disk (QTD)

The QNX Trusted Disk (QTD) device provides integrity protection of read-only filesystems and can extend secure boot to system-level filesystems. It can also serve as an integrity-protected container.

For more information, see Filesystem security in Security features for system integrators.

File-based encryption

The Power-Safe filesystem (fs-qnx6.so) provides file-based encryption support.

For more information, see Filesystem security in Security features for system integrators.

Cryptography support

QNX OS supports multiple ways to access cryptography services. It provides its own flexible cryptography framework that allows customers to choose which cryptography provider responds to requests on a per-process basis. In also ships with the popular OpenSSL library and a driver that interacts with the legacy /dev/crypto system device.

For information on choosing the cryptography resource for a process, see Cryptography for developers. For information on system cryptography resources, see Cryptography for system integrators.

Random number generator

The configurable random driver services the /dev/random and /dev/urandom system interfaces.

For more information, see Random number generation in Security features for system integrators.

Authentication

Pluggable Authentication Module (OpenPAM) is available for authentication-related system functions.

For more information, see Systems without passwords in Security features for system integrators and PAM.

Driver isolation

QNX OS runs filesystems, networking, and other system services as userspace processes. All protections listed above in Process Protections can be applied to system services running as userspace processes to limit the impact of a vulnerability in the system service.

Hardware memory isolation

IOMMUs that restrict hardware access to system memory are supported. Configuration of the memory management hardware is controlled by SMMUMAN.

Additional features and more information

Some features, or specific aspects of the available features, are of particular interest to software developers working on QNX OS projects, or to system integrators and system security specialists.

See Security for developers and Security for system integrators.

Page updated: