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

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

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

Bill McCarty

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید








5.2 Two Forms of an SELinux Policy


If you're familiar with a
programming language, such as C, you'll find that
working with an SELinux policy resembles working with a program.
Programs generally have two forms: a source form and an object form.
Programmers work with the source form of a program, which resides in
one or more ordinary text files. These files can be created and
changed using a text editor or interactive development environment
(IDE). However, you can't load and run the source
form of a program. Instead, you must use a compiler to translate the
source form into object form. The file that contains the object form
of a program is a binary file that cannot
be viewed or changed using a text editor. Figure 5-1 shows the process that transforms a program
from source to object form.


Figure 5-1. Transforming a program from source to object form

Figure 5-2 shows the process that transforms an
SELinux policy from source to binary (object) form. The


checkpolicy
command is analogous to the compiler that converts a program from
source to object form. Sometimes, therefore, the
checkpolicy command is referred to as the
SELinux policy compiler.

Unlike a typical compiler used to translate computer programs, the
checkpolicy command can take input from only one
source file. So, all SELinux policy source files are concatenated and
written to the policy.conf file. The
checkpolicy command reads the
policy.conf file and writes a
policy.??
file
containing a binary policy. The replaceable part of the binary policy
filename indicates the version number of the SELinux policy language
that was used to create the binary policy. For instance, a binary
policy having filename policy.17 would relate to
Version 17 of the SELinux policy language.

The binary form of an SELinux policy can be loaded into a running
Linux kernel by issuing a load_policy command
specifying the binary policy filename as an argument. However, as
explained in Chapter 4, the system
administrator generally uses the SELinux
Makefile to load a policy. The


make install,
make load, and make reload
commands cause the SELinux Makefile
to issue the load_policy command.


Figure 5-2. Transforming an SELinux policy from source to binary form

Because the SELinux policy compiler can read only one file, it may
seem odd that an SELinux policy is organized as a set of files.
Indeed, it would be possible for the policy to reside only in
policy.conf. However, a typical SELinux policy
contains almost 250,000 lines of code. Editing such a large file
would be quite cumbersome. So the SELinux policy is distributed
throughout a directory tree, typically rooted at
/etc/security/selinux/src/policy. The principal
subdirectories of this directory tree include:

appconfig


Defines default types and security
contexts for several special circumstances.


domains


Defines
the type-enforcement domains.


file_contexts


Defines the security contexts of
persistent files.


flask


Defines
symbols used by the SELinux-capable kernel.


macros



Defines M4 macros used in policy
source files.


tmp


Concatenates policy source files
during policy compilation.




The tmp directory is merely a working directory
used during SELinux Makefile operations and
therefore has no permanent contents. It is not further explained in
this chapter.

types


Defines
several general typesthat is, types not
associated with particular domains.



Because the contents of the SELinux policy files are concatenated and
written to policy.conf before being compiled,
the SELinux policy compiler isn't aware which
SELinux policy file contains the policy statements it compiles. But
humans find it convenient to place related policy statements in a
single file. Doing so makes it easier to understand the policy, which
can be studied a file or two at a time, rather than all at once. And
distributing statements among a set of files makes it easier to
locate a statement of interest, because you can often deduce which
files are most likely to contain it. So when creating or revising an
SELinux policy, it's important to observe the
conventions used by the original developers of the policy. These
conventions are described more fully in the section of this chapter

titled
"SELinux Policy Structure."


/ 100