Filesystem security

File systems and mount points

Best practices for securing file systems and mount points include the following:

• Use the io-blk.so library's mntperms, mntuid and mntgid options to control the permissions of mount points, if required (see io-blk.so in the Utilities Reference).
• Pay attention to how you set ownership, file permissions, and access modes. For example, if a file is not meant to be written to, make it non-writable.
• Mark all executables as non-writable or use an integrity protected disk solution such as QNX Trusted Disk.
• Many UNIX systems have mountpoints that require you to create a node or directory in an underlying filesystem before mounting a new filesystem at that point. However, QNX Neutrino does not. Don't rely on parent directory permissions to protect the mountpoint of an attached pathname space.
• There is no exclusivity of mountpoints when filesystems are unioned. Use security policies to restrict mountpoints that can be registered. To prevent resource managers from being accessed by specific clients, use security policies. Using POSIX permissions and access control lists (ACLs) on the parent directory of a mountpoint does not prevent the mountpoint from being accessed. Check the POSIX permissions and ACLs before you grant access to a client.

QNX Trusted Disk

QNX Trusted Disk (QTD) devices provide integrity protection of the underlying disk data in secure boot environments. They can extend the secure boot chain up to the core operating system filesystem that stores additional system binaries and configuration files.

QTD can also be used as a protected container format (app model).

For complete information, see “QNX Trusted Disk” in the System Architecture guide.

File-based encryption

The Power-Safe filesystem supports file-based encryption where files and folders are aggregated into encryption domains. Each domain has a unique encryption key which encrypts the unique file encryption key. Access to the files require that some external actor unlock the domain, providing the domain encryption key to the filesystem driver, allowing it to decrypt the file encryption key and granting access to the encrypted file contents.

For more information, see “Encryption” in the “Filesystems” chapter of the System Architecture guide.

Unioned filesystems

Although QNX Neutrino supports unioned filesystems, they are generally a bad idea and only useful in a limited number of situations that you are unlikely to encounter. Further, unioned filesystems incur a performance penalty when searching for files that may reside on any of the unioned filesystems.

The QNX Neutrino IFS is unioned by default and mounted at "/'"and all files in the IFS are prefixed with proc/boot. This incurs a performance penalty on object path lookup starting with /proc because the /proc filesystem (procfs) is always mounted first at startup time by procnto. Add these lines to your IFS build file to mount the IFS at its own mount point (/ifs) and also gain a minor performance boost.

[prefix=]
[mount=/ifs]