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

9.6 Adding Permissions

At this
point in the development of SELinux, it's common for
policies to contain small bugs that cause operations to fail when
applications or programs are used in unusual ways unanticipated by
policy developers. As an SELinux administrator, one of the most
frequent SELinux policy customizations you're likely
to perform is adding permissions to coax the security engine into
accepting an operation. Let's consider an actual
situation based on Fedora Core 2's SELinux
implementation and see how it's resolved. The
procedure we'll follow isn't the
only procedure or best procedure. Creating new policies typically
entails a generous dollop of troubleshooting, which tends to be
relatively unstructured. So rather than see our procedure as the
universal norm, you should see it as merely an illustrative example.

Though unfamiliar to many, the Nmap program is a popular tool among those
concerned with security that provides many useful functions. For
instance, using Nmap, you can determine the ports on which a network
host is listening and what service is running on each open port.

Suppose you install and run Nmap and obtain the following error
message:

#nmap -sT 127.0.0.1
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-06-01 17:23 UTC
Unable to find nmap-services!  Resorting to /etc/services

It seems that Nmap is unable to read the nmap-services file.
Checking the system log, you find that SELinux recently logged eight
denial messages:

avc:  denied  { read } for  pid=8682 exe=/usr/bin/nmap name=urandom dev=dm-0
ino=306563 scontext=root:sysadm_r:traceroute_t tcontext=system_u:object_r:urandom_ 
device_t tclass=chr_file
avc:  denied  { read } for  pid=8682 exe=/usr/bin/nmap name=random dev=dm-0
ino=301298 scontext=root:sysadm_r:traceroute_t tcontext=system_u:object_r:random_ 
device_t tclass=chr_file
avc:  denied  { read } for  pid=8682 exe=/usr/bin/nmap name=urandom dev=dm-0
ino=306563 scontext=root:sysadm_r:traceroute_t tcontext=system_u:object_r:urandom_
device_t tclass=chr_file
avc:  denied  { read } for  pid=8682 exe=/usr/bin/nmap name=random dev=dm-0
ino=301298 scontext=root:sysadm_r:traceroute_t tcontext=system_u:object_r:random_
device_t tclass=chr_file
avc:  denied  { read } for  pid=8682 exe=/usr/bin/nmap name=localtime dev=dm-0
ino=32810 scontext=root:sysadm_r:traceroute_t tcontext=system_u:object_r:locale_t 
tclass=file
avc:  denied  { search } for  pid=8682 exe=/usr/bin/nmap name=root dev=dm-0
ino=262145 scontext=root:sysadm_r:traceroute_t tcontext=root:object_r:staff_home_dir_
t tclass=dir
avc:  denied  { read } for  pid=8682 exe=/usr/bin/nmap name=nmap-services dev=dm-4
ino=231156 scontext=root:sysadm_r:traceroute_t tcontext=system_u:object_r:usr_t 
tclass=file
avc:  denied  { search } for  pid=8682 exe=/usr/bin/nmap name=policy dev=dm-0
ino=49161 scontext=root:sysadm_r:traceroute_t tcontext=system_u:object_r:policy_src_t
tclass=dir

Notice that Nmap runs in the domain
traceroute_t
; we'll use that
information later. For now, focus on the seventh message, which is
next to last. This message shows that the security engine denied read
access to the nmap-services file. However, the
message gives only the base filename, not the full path. You can find
the location of the file by using the locate
command:

#locate nmap-services
/usr/share/nmap/nmap-services

Next, double check the security context of the file:

#ls -Z /usr/share/nmap
-rw-r--r--  root     root     system_u:object_r:usr_t          nmap-os-fingerprints
-rw-r--r--  root     root     system_u:object_r:usr_t          nmap-protocols
-rw-r--r--+ root     root     system_u:object_r:usr_t          nmap-rpc
-rw-r--r--  root     root     system_u:object_r:usr_t          nmap-service-probes
-rw-r--r--  root     root     system_u:object_r:usr_t          nmap-services

The security context, system_u:object_r:usr_t
,
agrees with that shown in the log message. Apparently, the
traceroute_t
domain does not have permission to
read files in the security context
system_u:object_r:usr_t
, including the
nmap-services file.

Now that we understand the problem, let's fix it. We
could give the traceroute_t
domain read access to
the system_u:object_r:usr_t
security context by
adding the following declaration to the SELinux policy:

allow traceroute_t usr_t:file { read };

However, adding this declaration would enable access to files other
than nmap-services and might compromise system
security. We need a more focused fix.

Let's examine the FC file for the
traceroute_t

domain, file_contexts/program/traceroute.fc:

#traceroute
/bin/traceroute.*       --      system_u:object_r:traceroute_exec_t
/usr/(s)?bin/traceroute.* --    system_u:object_r:traceroute_exec_t
/usr/bin/lft            --      system_u:object_r:traceroute_exec_t
/usr/bin/nmap           --      system_u:object_r:traceroute_exec_t

Notice that the only security context referenced in the FC file is
system_u:object_r:traceroute_exec_t
. This context
is used to label the Nmap executable and other executable files. So,
it doesn't seem to be an appropriate security
context for the nmap-services file. However, it
does seem appropriate to label the file with a security context based
on the domain type traceroute_t
.
Let's add the following line to the FC file:

/usr/share/nmap.*                system_u:object_r:traceroute_t

This line should cause the /usr/share/nmap
directory and the files it contains to be labeled with the security
context system_u:object_r:traceroute_t
. To
relabel the directory, issue the
commands:

#make load
#setfiles file_contexts/file_contexts /usr/share/nmap

Next, double check the result of the relabeling, which turned out
okay:

#ls -Z /usr/share/nmap
-rw-r--r--  root     root     system_u:object_r:traceroute_t   nmap-os-fingerprints
-rw-r--r--  root     root     system_u:object_r:traceroute_t   nmap-protocols
-rw-r--r--+ root     root     system_u:object_r:traceroute_t   nmap-rpc
-rw-r--r--  root     root     system_u:object_r:traceroute_t   nmap-service-probes
-rw-r--r--  root     root     system_u:object_r:traceroute_t   nmap-services

Now, retry the command:

#nmap -sT 127.0.0.1
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-06-01 17:46 UTC
Unable to find nmap-services!  Resorting to /etc/services

Again, the command fails. Checking the log, we find a relevant AVC
message:

avc:  denied  { search } for  pid=8753 exe=/usr/bin/nmap name=nmap dev=dm-4 ino=100533 
scontext=root:sysadm_r:traceroute_t tcontext=system_u:object_r:traceroute_t tclass=dir

We've made progress, but we haven't
yet resolved the problem. Now, we've run afoul of
the traceroute_t
domain, lacking permission to
search the /usr/share/nmap directory. Often
it's convenient to avoid this sort of step-by-step
discovery of successive problems by running the system in permissive
mode. But since the system is attached to the Internet, we prefer to
continue running in enforcing mode. We could temporarily take the
system offline, but that could be inconvenient for some users. So we
choose to continue as we've begun.

Let's authorize the traceroute_t

domain to search traceroute_t
directories. To do
so, add the following line to the
domains/program/traceroute.te file:

allow traceroute_t traceroute_t:dir { search };

After adding the line, load the revised policy and retry Nmap, which
again fails:

#make load
#nmap -sT 127.0.0.1
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-06-01 17:46 UTC
Unable to find nmap-services!  Resorting to /etc/services

This time, the log shows that Nmap was again prohibited from reading
the
nmap-services file but that the file is
correctly labeled with the new security context:

avc:  denied  { read } for  pid=8822 exe=/usr/bin/nmap name=nmap-services dev=dm-4 ino=231156 scontext=root:sysadm_r:traceroute_t tcontext=system_u:object_r:traceroute_t tclass=file

Apparently, the traceroute_t
domain
isn't authorized to read
traceroute_t
files. So we must add another line to
traceroute.te, one authorizing the
traceroute_t
domain to read its own files:

allow traceroute_t traceroute_t:file { read };

Again, load the new policy and retry Nmap. This time, Nmap works as
it should:

#nmap -sT 127.0.0.1
Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-06-01 18:02 UTC
Interesting ports on bill-a31 (127.0.0.1):
(The 1658 ports scanned but not shown below are in state: closed)
PORT    STATE SERVICE
22/tcp open  ssh
Nmap run completed -- 1 IP address (1 host up) scanned in 0.467 seconds

This case study is typical of what you may encounter when running
programs with SELinux policies that are less than complete and error free.