IBM 10 SP1 EAL4 User Manual

On SLES, a binary executable automatically causes the program loader /lib/ld-linux.so.2 to 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.

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.

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