| Updated: April 19, 2023 |
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 Neutrino'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.
QNX Neutrino supports stack cookies and all stacks are non-executable by default. Stack canaries are enabled in prebuilt QNX Neutrino 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”.
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 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”.
The C library for QNX Neutrino provides fortified versions of various system functions that check their arguments at compile time, runtime, or both for conditions such as:
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”.
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.
One approach to reduce the impact of system-wide Denial of Service (DoS) attacks is by using resource limits. QNX Neutrino supports setting limits on CPU use, memory use, open connections, and other system resources.
For more information, see prlimit() in the C Library Reference.
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”.
QNX Neutrino 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”.
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 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”.
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 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”.
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”.
The Power-Safe filesystem (fs-qnx6.so) provides file-based encryption support.
For more information, see “Filesystem security” in “Security features for system integrators”.
QNX Neutrino 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”.
The configurable random driver services the /dev/random and /dev/urandom system interfaces.
For more information, see “random” in “Security features for system integrators”.
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”.
Adaptive partitioning is an availability feature that allows processes in the system to be configured into groupings that are allocated CPU budget resources, making sure that critical system functions are not starved for resources by a buggy or malicious process.
QNX Neutrino 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.
IOMMUs that restrict hardware access to system memory are supported. Configuration of the memory management hardware is controlled by SMMUMAN.
Some features, or specific aspects of the available features, are of particular interest to software developers working on QNX Neutrino projects, or to system integrators and system security specialists.
See “Security for developers” and “Security for system integrators”.