Getting back to the basics

SELinux is a reimplementation of a design engineered by the U.S. government and The University of Utah known as the FLUX Advanced Security Kernel (FLASK). The SELinux and FLASK architecture provide a central policy file utilized while determining the results of access control decisions. This central policy is in a whitelist form. This means that all access control rules must be defined explicitly by the policy file. This policy file is abstracted and served by a software component called a security server. When the Linux kernel needs to make an access control decision and SELinux is enabled, the kernel interacts with the security server by means of the LSM hooks.

In a running system, a process is the active entity that gets time on the CPU to perform tasks. The user merely invokes these processes to do the work on their behalf. This is an important concept. As we type this book, we trust that the word processors running on our machines with our credentials aren't opening our SSH keys and embedding them in the document metadata. Right now, the process is in control of the computing resources, not the user. The process is the running entity, it is the process that makes system calls to the kernel for resources, not the physical human being. With this in mind, the very first actor in this SELinux system is the process, typically referred to as the subject. It is the subject that accesses files. It is the subject that the security server will use to make access decisions on.

Consequently, the subject utilizes kernel resources. This kind of kernel resource is an example of a target. The subject performs actions on the target. Naturally, one should ask, "What actions does a subject perform?" These are known as access vectors and typically correlate to the name of the syscall performed. For example, the subject could perform an open on the target. It is important to note that targets could be processes as well. For instance, if the system call is ptrace, the subject could be something along the lines of a debugger, and the target would be the process you wish to debug. A subject is frequently a process, but a target could be a process, socket, file, or something else.