Like other onetime elementary and secondary students, you've probably endured many school lectures on the subject of English grammar. If you're old enough, you may even have endured that most feared exercise of secondary education (which is now largely extinct): the sentence diagram, like that shown in Figure 2-1. Figure 2-1. A simple sentence diagram At the time of your elementary and secondary studies, the various parts of speech ”nouns, verbs, adjectives, adverbs, and so on ”and components of sentence structure ”subjects, actions, direct and indirect objects, and so on ”may not have seemed to you and your fellow students to be the most fascinating of topics. And, unless in adult life you've worked as a writer or editor, your aversion may seem to have been well-founded: many adults seem to get through life quite well with only a very fragmentary understanding of English grammar. If I claimed that knowledge of English grammar would help you better secure your computer systems, would that influence your estimate of the value of its study? Perhaps not. But my claim would nevertheless be true. The security model that underlies SELinux is based on simple grammatical concepts common to English and most other human languages, as well as artificial languages such as computer programming languages. Some scientists believe that an understanding of these concepts is more or less intrinsic to humankind ”encoded in the structure of the human mind itself ”and quietly shapes the way we view and understand reality. Of course, if grammar is truly innate, one may well wonder why it's necessary to teach it to students. But rather than get sidetracked by a debate over psycholinguistics (as the study of the grammatical mind is called), let's explore the relationship between grammar, SELinux, and computer security. At its root, the SELinux security model encompasses three elements: Subjects are the actors within a computer system. You might initially think that users would be the subjects of the SELinux security model, especially if your experience with computer systems has been primarily with desktop ”rather than server ”systems. However, users don't crawl inside their computers and act directly on the bits and bytes that compose computer systems. Instead, processes are the true actors. However, processes often act as surrogates for human users. So subjects and users are closely associated, even though processes ”not users ”are the true actors. Processes and Programs If you're not a programmer, the distinction between processes and programs may not be obvious. Or even if you are a programmer, you may be confident that you understand the distinction, but be unable to readily articulate it. Simply put, a program is an executable file, whereas a process is a program that has been read into memory and has commenced execution. For instance, if you start two identical terminal windows on your graphical desktop, you have started two processes that run the same program. Unlike a program, a process has state information. The state information associated with a process records the identity of the user account running the process, the instruction pointer (which indicates the next instruction to be executed), the value of every active program variable, and a variety of other information. Because processes and programs are closely related , some folks like to think of processes as programs in motion. | In grammar, subjects operate on objects. The same is true in the SELinux security model, where subjects (processes) also operate on objects. As summarized in Appendix A, SELinux defines several dozen security classes (or, more simply, classes ) of objects, including such workhorses as: -
Directories -
File descriptors -
Files -
Filesystems -
Links -
Processes -
Special files of various types (block device, character device, socket, FIFO, and so on) Notice that processes can serve as both subjects and objects of actions. In Linux, many kinds of entities are represented as files. In particular, directories, devices, and memory can all be accessed as files. So the most common class of SELinux object that subjects act upon is a file. Table 2-1 describes the object security classes defined by SELinux. Table 2-1. SELinux object security classes Class | Description | File classes | | blk_file | Block device file | chr_file | Character device file | dir | Directory | fd | File descriptor | fifo_file | FIFO file | file | File | filesystem | Formatted filesystem residing on disk partition | lnk_file | Hard or symbolic link | Interprocess communication classes | | ipc | (Obsolete) | msg | Interprocess communication message within queue | msgq | Interprocess communication queue | sem | Interprocess communication semaphore | shm | Interprocess communication shared memory | Network classes | | key_socket | IPSec socket | netif | Network interface | netlink_socket | Socket used to communicate with kernel via the netlink syscall | node | TCP/IP network host, as represented by IP address | packet_socket | Obsolete object type used by Linux 2.0 programs invoking the socket syscall | rawip_socket | Raw IP socket | sock_file | Network socket file | socket | Generic socket | tcp_socket | TCP socket | udp_socket | UDP socket | unix_dgram_socket | Unix-domain datagram socket | unix_stream_socket | Unix-domain stream socket | Object class | | passwd | Linux password file | System classes | | capability | SELinux capability | process | Process | Security | Security-related objects, such as the SELinux policy | System | Kernel and system objects | The actions that SELinux subjects perform upon objects vary with the type of object. For instance, a subject can perform such operations as these on file objects: -
Append -
Create -
Execute -
Get attribute -
I/O control -
Link -
Lock -
Read -
Rename -
Unlink -
Write | The preceding list of actions is not comprehensive. As explained in Chapter 5, SELinux recognizes over one dozen actions that can be performed on files. And, as mentioned in the preceding text, other object classes exist. These classes have many related actions. | | Using this simple framework ”subjects, actions, and objects ”we can identify the fundamental operation performed by the SELinux security server: determining whether a given subject is permitted to perform a given action on a given object. For instance, SELinux decides questions such as: Is process 24691 permitted to read the file known as /etc/shadow? To make such decisions, the SELinux security server consults its policy database . By basing security decisions on policies stored in a database, SELinux achieves a high degree of flexibility. Figure 2-2 illustrates this sample decision. Figure 2-2. A typical SELinux decision Linux and SELinux: Dueling Security Mechanisms? As explained in the preceding chapter, Linux has its own system of discretionary access control (DAC). How does Linux DAC interoperate with the mandatory access control (MAC) provided by SELinux? Do we end up with dueling security mechanisms? Fortunately, Linux DAC and SELinux MAC play well together. When making security decisions, SELinux first hands off the decision to Linux DAC. If DAC forbids an action, the action is not permitted. If, on the other hand, DAC permits an action, then SELinux performs its own authorization check, based on MAC. A requested action is allowed to occur only if both the Linux DAC and SELinux MAC authorizations are approved. | |