2.1 Subjects and Objects

     

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
figs/selx_0201.gif

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

  • 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 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
figs/selx_0202.gif

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.




SELinux. NSA's Open Source Security Enhanced Linux
Selinux: NSAs Open Source Security Enhanced Linux
ISBN: 0596007167
EAN: 2147483647
Year: 2003
Pages: 100
Authors: Bill McCarty

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net