Filter
Top Products
4.1.2.1 DAC
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.
4.1.2.1.1 Subjects and objects
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.
4.1.2.1.2 Attributes
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.
4.1.2.1.3 Access control rules
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.
4.1.2.1.4 Software privilege
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.
4.1.2.2 AppArmor
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