chroot (change root)
The QNX OS chroot() function allows you to set the root directory of a process to a path other than the system's root directory, a feature common to most UNIX-like operating systems.
You can use chroot to increase system security by limiting a process’s access to a filesystem. However, you have to be aware of potential pitfalls.
If a process whose root directory has been changed via chroot() (i.e., a chrooted process) has the ability to run a setuid program, it might be able to direct the setuid program to access files that are under its control. For example, a process is chrooted to /new_root, which allows it to create the file /new_root/etc/shadow. If the setuid program tries to open /etc/shadow to check passwords, it opens /new_root/etc/shadow instead and accesses passwords that are chosen by the chrooted process—a serious security problem. Similarly, a chrooted program might be able to create shared objects that the setuid program loads. These shared objects could be the source of code that the chrooted program then runs in the context of a privileged process.
(For more information, go to the chroot() entry in the C Library Reference.)
Accessing paths outside of a process's root directory
Ordinarily, a process is restricted to accessing paths that are within its root directory. This restriction is a problem if a process needs to access resource managers or files that are located outside of the chroot path. If the process needs to spawn other processes, common shared objects such as ldqnx-64.so and libc.so.x will also be outside its root directory (unless copies were made at the appropriate locations).
To get around this issue, before chroot() is called, create a process manager symbolic link (symlink) at a location that will be within the chroot. This symlink must be created before chroot() is called to grant access to the path outside the chroot. For example, you create the symlink /new_root/dev/random that points to /dev/random. A process that subsequently calls chroot() to change the root directory to /new_root and then tries to open the path /dev/random can successfully open the system-relative path /dev/random. You can also use this method to make whole directories available. For example, a symlink /new_root/system/lib that points to /system/lib provides access to all shared objects contained in /system/lib.
Note that you can only use process manager symlinks, not regular symlinks, for this purpose. In this context, the symlinks serve a dual function: they provide the usual symlink function of redirecting one path to another, and also authorize the process's access to the path that it points to.
(For more information, go to Process manager symbolic links
in System
Architecture and the pathmgr_symlink() entry in the C
Library Reference.)
Reference to system-relative, absolute paths
For any filesystem operation that involves a path, if the path begins with at least three forward slashes (/), it is interpreted as being system absolute instead of relative to the root path of the process.
Although a chrooted process can specify paths that are system absolute, this configuration by itself does not permit the process to access the path. A process is allowed to access:
- paths that are in the process's root directory and its subdirectories, or
- a path pointed to, or whose parent directory is pointed to, by a process manager symlink in the process's root directory or one of its subdirectories. This symlink must be created before the process is chrooted.
As an example of using system absolute paths, the dynamic loader is, by default, accessed at /usr/lib/ldqnx-64.so.2. You can set the procnto LDQNX environment variable in the buildfile for the IFS to override the dynamic loader to be a system-absolute path. For example, a buildfile includes the following entry:
LDQNX=///proc/boot/ldqnx-64.so.2
procnto-smp-instr -v -mr -d 0777 -u 0777
When LDQNX is set to this value, the dynamic loader is always accessed from the system absolute path /proc/boot/ldqnx-64.so.2, even within a chroot. A procmgr symlink within the chroot must still point to either /proc/boot/ldqnx-64.so.2 or a parent path for access to be granted.
The CHROOT ability
Because chrooting a process can affect system security, the ability to use chroot is controlled by the CHROOT ability. For more information, go to the chroot() entry in the C Library Reference.