Appendix: Caveats

This section contains important caveats about the QNX Containers implementation. For more information, please refer to the QNX Containers Cybersecurity Manual.

Service restart

Restarting container services involves slaying both the processes, qrunc and qcmgr, before relaunching them again. If you have created a large number of pods and qcmgr is terminated, all the pods and their configurations is gracefully taken down. You must wait for the termination process to complete before restarting another instance of qcmgr. You can run pidin to verify that qcmgr is no longer running. Similarly, after restarting qcmgr, all pods existing before the restart is re-created, and also all existing containers are re-created (but not started), and that also takes time. You can manually check if the path /dev/containers/qcmgr exists before sending new commands.

Network jails

Network isolation in containers is achieved using the QNX Network Jail feature.

In QNX Containers 1.0, there's a known issue in which a sub-process associated with a container to lose its network jail configuration and be unable to use networking. A known use case where this can occur is in a legacy application which uses fork or exec to create a daemon process. To mitigate the risk of this happening, the following are suggested:

Use procmgr_daemon to create a daemon process, instead of fork or exec.
Use spawn instead of fork or exec.
Don't exit the parent process before the child process has been created and has started running.

Setuid applications

Some applications (e.g., ping) have the setuid bit set so they always run with permissions of the file owner (typically root). When qrunc spawns a process and it receives an exec command, the setuid bit is overridden and the process runs as the container user or the specified user, instead of the owner. In general, it's recommended to avoid the need for setuid bits as they present a possible security risk.

Privileged applications

CAUTION:

QNX Containers doesn't prevent privileged applications from affecting the host. For example, if the shutdown command is accessible in a container and can be run as root, then executing this command in the container shuts down the host. To prevent the shutdown, the easiest way is to ensure that the container doesn't run with root privilege and doesn't have access to those kinds of commands.

Process visibility

QNX Containers doesn't support a separate container process namespace. When you run pidin or query process information from within a container, all processes on the host are visible (if running as root).