Security

Secure processes have some restrictions applied to the evaluation of their dependencies and runpaths to prevent malicious dependency substitution or symbol interposition.

The runtime linker categorizes a process as secure if the user is not a super-user, and either the real user and effective user identifiers are not equal, or the real group and effective group identifiers are not equal. See getuid(2), geteuid(2), getgid(2) and getegid(2).

The default trusted directory known to the runtime linker is /usr/lib/secure for 32-bit objects or /usr/lib/secure/64 for 64-bit objects. The utility crle(1) may be used to specify additional trusted directories applicable for secure applications. Administrators who use this technique should ensure that the target directories are suitably protected from malicious intrusion.

If an LD_LIBRARY_PATH family environment variable is in effect (see "Directories Searched by the Runtime Linker") for a secure process, then only the trusted directories specified by this variable will be used to augment the runtime linker's search rules.

In a secure process, any runpath specifications provided by the application or any of its dependencies (see "Directories Searched by the Runtime Linker") will be used, provided they are full pathnames, that is, the pathname starts with a `/'.

In a secure process, the expansion of the $ORIGIN string (see "Security") is allowed only if it expands to a trusted directory.

Additional objects can be loaded with a secure process using the LD_PRELOAD (see "Loading Additional Objects") or LD_AUDIT (see "Runtime Linker Auditing Interface") environment variables. These objects must be specified as full pathnames or simple filenames. Full pathnames are restricted to known trusted directories. Simple file names, in which no `/' appears in the name, are located subject to the search path restrictions previously described, and thus will only resolve to known trusted directories.

In a secure process, any dependencies that consist of simple filenames will be processed using the pathname restrictions previously described. Dependencies that are expressed as full or relative pathnames will be used as is. Therefore, the developer of a secure process should ensure that the target directory referenced as a full or relative pathname dependency is suitably protected from malicious intrusion.

When creating a secure process, it is recommended that relative pathnames not be used to express dependencies or to construct dlopen(3DL) pathnames. This restriction should be applied to the application and to all dependencies.