IBM 10 SP1 EAL4 Manuale Utente

The DAC model allows the owner of the object to decide who can access that object, and in what manner. 
Like any other access control model, DAC implementation can be explained by which subjects and objects 
are under the control of the model, security attributes used by the model, access control and attribute 
transition rules, and the override (software privilege) mechanism to bypass those rules.

Subjects in SLES are regular processes and kernel threads.  They are both represented by the task_struct 

structure.  Kernel threads run only in the kernel mode, and are not constrained by the DAC policy.  All named 
objects such as regular files, character and block files, directories, sockets, and IPC objects are under the 
control of the DAC policy.

Subject attributes used to enforce DAC policy are the process UID, GID, supplementary groups, and process 
capabilities.  These attributes are stored in the task_structure of the process, and are affected by the 

system calls as described in Section 5.2.  Object attributes used to enforce DAC policy are owner, group 
owner, permission bits, and POSIX.1e Access Control Lists (ACLs).  These attributes are stored in-core and, 
for appropriate disk-based file systems, in the on-disk inode.

DAC access control rules specify how a certain process with appropriate DAC security attributes can access 
an object with a set of DAC security attributes.  In addition, DAC access control rules also specify how 
subject and object security attributes transition to new values and under what conditions.  DAC access control 
lists are described in detail in Section 5.1.5.

Software privilege for DAC policy is based on the user ID of the process.  At any time, each process has an 
effective user ID, an effective group ID, and a set of supplementary group IDs.  These IDs determine the 
privileges of the process.  A process with a user ID of 0 is a privileged process, with capabilities of bypassing 
the access control policies of the system.  The user name root is commonly associated with user ID 0, but 
there can be other users with this ID.
Additionally, the SLES kernel has a framework for providing software privilege for DAC policy through 
capabilities.  These capabilities, which are based on the POSIX.1e draft, allow breakup of the kernel software 
privilege associated with user ID zero into a set of discrete privileges based on the operation being attempted. 
For example, if a process is trying to create a device special file by invoking the mknod() system call, then 

instead of checking to ensure that the user ID is zero, the kernel checks to ensure that the process is capable of 
creating device special files.  In the absence of special kernel modules that define and use capabilities, as is 
the case with the TOE, capability checks revert back to granting kernel software privilege based on the user 
ID of the process. 

With AppArmor, it is the system security policy/administrator, unlike the owner in DAC, that controls which 
files subjects should be allowed to access.  AppArmor is implemented as a Linux Security Module (LSM) and 
is an optionally loaded component of SLES. AppArmor is not required to enforce the security functionality 
required by the Controlled Access Protection Profile and can only add additional restrictions.  

21