IBM 10 SP1 EAL4 manual Library linking mechanism, System call linking mechanism

5.16.2Library linking mechanism

On SLES, a binary executable automatically causes the program loader /lib/ld-linux.so.2to be loaded and run. This loader takes care of analyzing the library names in the executable file, locating the library in the system directory tree, and making requested code available to the executing process. The loader does not copy the library object code, but instead performs a memory mapping of the appropriate object code into the address space of the executing process. This mapping allows the page frames containing the object code of the library to be shared among all processes that invoke that library function.

Page frames included in private regions can be shared among several processes with the Copy On Write mechanism. That is, the page frames can be shared as long as they are not modified. The page frames containing the library object code are mapped in the text segment of the linear address space of the program. Because the text segment is read-only, it is possible to share executable code from the library among all currently executing processes.

The kernel carries out this mapping of page frames in a read-only text segment, without any input from the user. Object code is shared in read-only mode, preventing one process from making an unauthorized modification to another process’s execution context, thus satisfying the DAC requirement. Page frames used for this mapping are allocated with the demand paging technique, described in Section 5.5.2.5.6, which satisfies the object reuse requirement.

On SLES systems, the administrator can control the list of directories that are automatically searched during program startup. The directories searched are listed in the /etc/ld.so.conf file. A normal user is not allowed write access to the /etc/ld.so.conf file. The loader also allows certain functions to be overridden from shared libraries with environment variables LD_PRELOAD and LD_LIBRARY_PATH.

The LD_PRELOAD variable lists object files with functions that override the standard set. The

LD_LIBRARY_PATH variable sets up lists of directories that are searched before loading from the standard directory list. In order to prevent a normal user from violating the security policy, these variables are ignored, and removed from the process’s environment when the program being executed is either setuid or setgid.

The system determines if a program is setuid or setgid by checking the program's credentials; if the UID and EUID differ, or the GID and the EGID differ, then the system presumes the program is setuid or setgid, or descended from one, and does not allow preloading of user-supplied functions to override ones from the standard libraries. Similarly if the program execution results in domain transition then the system checks to see if the resulting domain possesses the type enforcement permission noatsecure. If noatsecure is not present then the system clears LD_PRELOAD and LD_LIBRARY_PATH variables and thus does not allow preloading of user-supplied functions to override ones from the standard libraries.

When an executable is created by linking with a static library, the object code from the library is copied into the executable. Because there is no sharing of page frames with other executing processes, there are no DAC or object reuse issues with static libraries.

5.16.3System call linking mechanism

A system call is an explicit request to the kernel made via a software interrupt. The implementation of this interrupt is dependent on the hardware architecture. The following subsections briefly describe the system call interrupt setup for the different hardware architectures that are part of the TOE.

5.16.3.1System x

On System x systems, the Interrupt Descriptor Table (IDT) for the Intel processors is initialized to allow a trap gate that can be accessed by a user-mode process. The trap_init() routine does this mapping at

215