Runtime 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
issetugid
(2) system call returns true for the process.
For 32-bit objects, the default trusted directories that
are known to the runtime linker are /lib/secure
and
/usr/lib/secure
. For 64-bit objects, the
default trusted directories that are known to the runtime linker are
/lib/secure/64
and
/usr/lib/secure/64
. The utility
crle
(1) can be used to specify additional trusted
directories that are 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 for a secure process, only the trusted directories specified by
this variable are used to augment the runtime linker search rules. See
Directories Searched by the Runtime Linker.
In a secure process, any runpath specifications provided by the application or any of its dependencies are used. However, the runpath must be a full path name, that is, the path name must start with a '/'.
In a secure process, the expansion of the $ORIGIN
string is
allowed only if the string expands to a trusted directory. See Security in Coded Processes. However, should a
$ORIGIN
expansion match a directory that has
already provided dependencies, then the directory is implicitly secure. This
directory can be used to provide additional dependencies.
In a secure process, LD_CONFIG
is ignored.
However, a configuration file that is recorded in a secure application is
used. See the -c
option of
ld
(1). A recorded configuration file must be a
full path name, that is, the path name starts with a '/'. A recorded
configuration file that employs the $ORIGIN
string is
restricted to known trusted directories. Developers who record a
configuration file within a secure application should ensure that the
configuration file directory is suitably protected from malicious intrusion.
In the absence of a recorded configuration file, a secure process uses the
default configuration file, if the configuration file exists. See
crle
(1).
In a secure process, LD_SIGNAL
is ignored.
Additional objects can be loaded with a secure process using the
LD_PRELOAD
or LD_AUDIT
environment
variables. These objects must be specified as full path names or simple file
names. Full path names 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. Simple file names resolve
only to known trusted directories.
In a secure process, any dependencies that consist of simple file names are processed using the path name restrictions previously described. Dependencies expressed as full path names or relative path names are used as is. Therefore, the developer of a secure process should ensure that the target directory referenced as one of these dependencies is suitably protected from malicious intrusion.
When creating a secure process, do not use relative path names to express
dependencies or to construct
dlopen
(3C) path names. This restriction applies to the
application and to all dependencies.