Security

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

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

If an LD_LIBRARY_PATH 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. Presently, the only trusted directory known to the runtime linker is /usr/lib.

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

Additional objects may be loaded with a secure process using the LD_PRELOAD environment variable (see "Loading Additional Objects") provided the objects are specified as simple filenames - in other words there is no `/' in the name. These objects will be located subject to the search path restrictions previously described.

In a secure process, any dependencies that consist of simple filenames will be processed using the pathname restrictions outlined. Dependencies that are expressed as full or relative pathnames will be used as is. Therefore, the developer of a secure process should insure 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(3X) pathnames. This restriction should be applied to the application and to all dependencies.