SELinux [Electronic resources] نسخه متنی

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

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.

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 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.

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.