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.
At the time of your elementary and secondary studies, the various parts of speechnouns, verbs, adjectives, adverbs, and so onand components of sentence structuresubjects, actions, direct and indirect objects, and so onmay 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 humankindencoded in the structure of the human mind itselfand 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
Objects
Actions
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 desktoprather than serversystems. 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 processesnot usersare the true actors.
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.
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 frameworksubjects, actions, and objectswe 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.
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.