Курсовая работа: Security-Enhanced Linux — линукс с улучшенной безопасностью
Имя пакета с исходными кодами целевой политики будет иметь вид: selinux-policy-targeted-sources-<номер_версии>.noarch.rpm
После установки исходные коды можно будет найти в директории: /etc/selinux/targeted/src/policy/
Для компиляции политики нужно сделать следующее:
cd /etc/selinux/targeted/src/policy/ (Перейти в директорию с исходными кодами).
make <make_policy_target> (Программа make запускает на исполнение так называемые MakeFile – некоторый аналог командных файлов BAT в Windows)
make install (Устанавливает политику в систему, но не загружает в ядро)
shutdown –r now (Перезагрузка системы. После перезагрузки новая политика будет загружена в систему и внесенную изменения вступят в силу)
Makefile компиляции целевой политики поддерживает следующие параметры:
install – компилирует, устанавливает политику, но не загружает в ядро. Правила установленной политики вступят в силу только после перезагрузки машины.
load - компилирует, устанавливает, и полностью загружает политику в память.
reload - компилирует, устанавливает, и загружает или перезагружает политику. Перезагрузка позволяет загружать политику без перезагрузки компьютера.
policy – только компилирование политики без ее установки в систему. Используется в основном для тестирования при разработке.
relabel - повторно маркирует файловую систему, используя источники политики, расположенные в файле $SELINUX_SRC/file_contexts/file_contexts. Такая операция проделывается при установки SELinux в систему. Данный параметр не рекомендуется к использованию без крайней необходимости.
enableaudit – разрешает журналировать те правила, которые помечены как dontaudit.
После компиляции мы получаем политику в двоичном формате имя которой имеет вид: policy.<XY>, где XY – это номер версии политики. Скомпилированная политика будет находиться в корне в папке с исходными файлами.
После загрузки в систему ее можно будет найти по пути /etc/selinux/targeted/policy.
2.1.6 Редактирование целевой политики
Файлы, содержащие политики для демонов, при использовании целевой политики располагаются в каталоге /etc/selinux/targeted/src/policy/domains/program/. Файлы с исходным кодом политик, обычно имеют расширение .te и соответствуют соглашению об именовании, например syslog.te.
Политики, или .te файлы, содержат правила для соответствующих доменов. Например, syslogd.te определяет правила работы в домене syslogd_t, включая такие операции как вывод журналов на консоль, изменение и создание файлов журналов, журналирование на внешний сервер и так далее.
Файл политики должен соответствовать файлу контекстов, или файлу .fc, расположенному в /etc/selinux/targeted/src/policy/file_contexts/program/. Файл контекстов содержит список контекстов безопасности, которые должны быть применены к файлам и каталогам, используемым демоном. Например, файл named.fc включает в себя:
/var/named(/.*)? system_u:object_r:named_zone_t
/var/named/data(/.*)? system_u:object_r:named_cache_t
Первая строка сообщает нам, что каталог /var/named/ имеет тип named_zone_t. Вторая строка сообщает, что каталог /var/named/data/ имеет тип named_cache_t.
/usr/sbin/named -- system_u:object_r:named_exec_t
Сообщает нам, что исполняемый файл named имеет тип named_exec_t. Соглашение об именовании для исполняемых файлов демонов выглядит так: X_exec_t, где X - это название домена демона.
Этот подход вызывает смену домена с unconfined_t на домен демона (в нашем примере, named_t) при запуске демона. При использовании строгой политики для корректной работы демоны должны быть запущены из административной сессии (роль sysadm_r и домен sysadm_t). При использовании целевой политики, данное требование не обязательно, т.к. unconfined_t - это единственный домен для входа пользователей (администратора или обычного пользователя).
Основной файл политики для named - это named.te, который содержит правила разрешающие доступ к домену named_t и определяет домен и смену домена на него. Наиболее важная часть в файле named.te: daemon_domain(named, `, nscd_client_domain')
Она определяет домен named_t и разрешает выполнение основных операций, таких как запись pid файла в /var/run, запуск порожденных процессов, журналирование с помощью syslog и так далее. Он также имеет политику для автоматической смены домена с unconfined_t на named_t при запуске исполняемого файла с типом named_exec_t.
Создание нового домена
Чтобы создать новый домен, администратор сначала должен создать новый файл .te в директории policy/domains и записать в него надлежащие TE правила и объявления. Чтобы задать новому домену набор базовых разрешений, следует использовать следующий макрос: general_domain_access(имя домена)
Создание нового типа
Чтобы создать новый тип, администратор должен сначала добавить его объявление в конфигурацию TE. Если этот тип ассоциирован с конкретным доменом, то его объявление следует поместить в файле .te этого домена. Если же это общий тип, то его объявление может быть помещено в один из файлов директории policy/types.
Далее необходимо задать правила доступа доменов к новому типу, а также правила перехода для этого типа. После этого политика вновь компонуется и загружается при помощи команды make load. Затем новый тип можно применить к файлу, путем обновления конфигурации файловых контекстов и запуска команды restorecon для этого файла.
В качестве примера возьмем именованный канал /dev/initctl, который используется для взаимодействия с процессом init. Тип initctl_t для этого файла определен в файле policy/domains/program/init.te, как показано ниже:
type initctl_t, file_type, sysadmfile;
Так как этот файл создается во время работы, должно быть создано правило перехода типов, чтобы гарантировать, что он всегда создается с этим типом. Это правило приведено ниже:
file_type_auto_trans(init_t, device_t, initctl_t)
Два других домена нуждаются в доступе к этому объекту: домен для скриптов /etc/rc.d и домен системного администратора. Отсюда, следующие правила TE разрешений добавлены в файлы политики policy/domains/program/initrc.te и policy/domains/admin.te:
allow initrc_t initctl_t:fifo_file rw_file_perms;
allow sysadm_t initctl_t:fifo_file rw_file_perms;
Далее политика может быть перегружена с помощью make load. Администратор должен добавить следующую запись в файл policy/file_contexts/program/init.fc и применить команду restorecon для файла:
dev/initctl system_u:object_r:initctl_t
Процесс создания пользователей, ролей и правил переходов будет рассмотрен на конкретном примере.
2.1.7 Написание новой политики для демона
Мы работаем с обычным демоном под Red Hat Enterprise Linux. Это значит, что есть его инициализирующий скрипт в /etc/init.d/ и им можно управлять используя chkconfig. К примеру, эта процедура подразумевает, что вы собираетесь использовать сервисную команду для управления запуском и остановкой демона.
По этой процедуре, вы пишете политику для пакета foo и ассоциированного с ним foo-демона.
Создайте файл $SELINUX_SRC/domains/program/foo.te.
Поместите макрос вызова демона в файл: daemon_domain(foo)
Создайте файл контекста файлов: $SELINUX_SRC/file_contexts/program/foo.fc.
Поместите первый список контекстов файлов в file.fc. Вам может понадобиться добавить кое-что к нему в дальнейшем, в зависимости от нужд демона
/usr/bin/foo -- system_u:object_r:foo_exec_t
/var/run/foo.pid -- system_u:object_r:foo_var_run_t
/etc/foo.conf -- system_u:object_r:foo_conf_t
Загрузите новую политику, используя make load.
Пометьте foo-файлы: restorecon /usr/bin/foo /var/run/foo.pid /etc/foo.conf
Запустите демона, service foo start.
Просмотрите лог аудита в поисках сообщений об отказе:
grep "avc: denied" /var/log/messages > /tmp/avc_denials
cat /tmp/avc_denials
Посмотрите, что foo_t домен пытается создать сетевой сокет, это udp_socket или tcp_socket, как объект класса в отказе AVC.
avc: denied { create } for pid=7279 exe=/usr/bin/foo \
scontext=root:system_r:foo_t tcontext=root:system_r:foo_t\
tclass=udp_socket
В таком случае, добавьте макрос can_network() в foo.te: can_network(foo_t)
Продолжайте эти действия по базовым шагам, чтобы создать все правила, которые вы хотите. Каждый набор правил, добавленный к политике, может потребовать дополнительных разрешений для foo_t домена.
Запустите демона.
Прочтите AVC сообщения.
Составьте правило используя эти сообщения и свои знания, пытаясь по возможности использовать макрос.
Загрузите новую политику.
Вернитесь к началу запустите демона.
Если демон пытается получить доступ к port_t, который связан с tclass=tcp_socket или tclass=udp_socket в логе АВЦ сообщений, вам необходимо определить, какой номер порта foo хочет использовать. Для диагностики (чтобы определить), поместите следующие правила в foo.te:
allow foo_t port_t:tcp_socket name_bind;
auditallow foo_t port_t:tcp_socket name_bind;
Продолжайте в том же духе по оставшимся AVC отказам. Когда они будут разрешены новой политикой, вы можете настроить уникальные требования для foo_t домена.
Запустив демона, определите, какой порт использует foo. Посмотрите на сообщение, разрешенное AVC и увидите, к какому порту подключен демон:
lsof | grep foo.*TCP
foo 2283 root 3u IPv6 3192 TCP *:4242 (LISTEN)
Foo-демон слушает порт 4242
Удалите общее правило port_t, заменив его специальным правилом для нового порта, основанным на домене foo_t.
type foo_port_t, port_type;
allow foo_t foo_port_t:tcp_socket name_bind;
Добавьте эту строку в $SELINUX_SRC/file_contexts. Это зарезервирует порт 4242 для домена foo_t:
ifdef(`foo.te', `portcon tcp 4242 system_u:object_r:foo_port_t')
2.2 Процессы в системе UNIX
2.2.1 Понятие и структура процесса
Процесс – это абстракция, применяемая в UNIX для описания выполняющейся программы. Это системный объект, посредством которого можно контролировать обращения программы к памяти, процессору и ресурсам ввода-вывода.
Компоненты процесса.
Процесс состоит из адресного пространства и набора структур данных, содержащихся внутри ядра. Адресное пространство представляет собой совокупность страниц памяти (базовые блоки размером, как правило, от 1 до 8 Кб), которые ядро выделило для выполнения процесса. В него загружается код процесса и используемые им библиотеки функций, переменные, стек и различная вспомогательная информация, необходимая ядру во время работы процесса. Поскольку в UNIX поддерживается концепция виртуальной памяти, страницы адресного пространства процесса в конкретный момент времени могут либо находиться в физической памяти целиком или частично, либо вообще отсутствовать там.
В структурах данных ядра хранится различная информация о каждом процессе. К наиболее важным относятся:
идентификационная информация о процессе;
статус процесса (неактивен, приостановлен, выполняется и т.п.);
информация для планировщика;
информация для организации межпроцессорного взаимодействия;
ссылки и связи процесса;
информация о времени исполнения и таймеры;
информация об используемых процессом ресурсах файловой системы;
информация о выделенном процессу адресном пространстве;
контекст процесса (информация о состоянии регистров процессора, стеке и т.д.)
Идентификатор процесса (PID).
Каждому новому процессу, созданному ядром, присваивается уникальный идентификатор (Process ID, PID). Большинство команд и системных вызовов, работающих с процессами, требуют указания конкретного идентификатора, чтобы был ясен контекст операции. Идентификационные номера присваиваются процессам по порядку по мере их создания. Когда номера заканчиваются, ядро сбрасывает счетчик в единицу и снова присваивает их по порядку, пропуская те идентификаторы, которые еще используются.
Идентификатор родительского процесса (PPID).
В UNIX нет системного вызова, который создавал бы новый процесс для выполнения конкретной программы. Вместо этого существующий процесс должен клонировать сам себя, чтобы породить новый процесс. Путь, по которому осуществляется клон, может отличаться от пути выполнения породившего его процесса.
Исходный процесс в терминологии UNIX называют родительским, а его клон порожденным или дочерним. Помимо собственного идентификатора, каждый процесс имеет атрибут PPID (Parent Process ID), который равен идентификатору родительского процесса, породившего данный процесс.
Идентификатор пользователя (UID) и идентификатор группу (GID).
UID (User ID) – это идентификатор пользователя, создавшего данный процесс. Вносить изменения в процесс могут только его создатель (владелец) и пользователь root.
GID (Group ID) – это идентификатор группы, к которой относится владелец процесса.
Приоритет и значение nice.
От приоритета процесса зависит, какую долю времени ЦП он получит. Ядро применяет динамический алгоритм назначения приоритетов, учитывающий, сколько времени ЦП уже использовал процесс и сколько времени он ожидает своей очереди. Кроме того, учитывается заданный административным путем так называемый фактор уступчивости (устанавливается с помощью команды nice), определяющий, в какой степени программа может «делиться» процессором с другими программами. Чем выше значение nice, тем «уступчивее» программа.
Управляющий терминал.
Большинство процессов имеют связанный с ними управляющий терминал. Он определяет базовую конфигурацию стандартных каналов ввода, вывода и ошибок. Когда пользователь вводит какую-либо команду в интерпретаторе shell, его терминал, как правило, становится управляющим терминалом процесса. От управляющего терминала также зависит распределение сигналов.
2.2.3 Создание новых процессов
Новые процессы создаются в Linux методом «клонирования» какого-то уже существующего процесса, путем вызова системных функций clone() и fork(). Процедура порождения нового процесса выполняется в режиме ядра и происходит следующим образом.
Создается новая структура в таблице процессов ядра и содержание такой же структуры старого (или текущего) процесса копируется в новую структуру.
Назначается идентификатор (PID) нового процесса. PID это уникальное положительное число, которое присваивается каждому процессу при его рождении. Именно по этим идентификаторам система различает процессы.
Увеличиваются счетчики открытия файлов (порожденный процесс наследует все открытые файлы родительского процесса).
После того, как процесс создан, запускается выполняемая им программа с помощью одного из вариантов системного вызова exec. Параметрами функции exec является имя выполняемого файла и, если нужно, параметры, которые будут переданы этой программе. Программа из указанного файла загружается в адресное пространство процесса, порожденного с помощью fork(), счетчик команд устанавливается в начальное значение и вновь созданный процесс переходит в режим ожидания того момента, когда планировщик выделит ему время центрального процессора.
В том процессе, откуда вызывались функции fork() и exec, управление передается в точку возврата из системного вызова и выполнение этого процесса продолжается. Родительский процесс может дожидаться окончания выполнения всех своих процессов-потомков с помощью системного вызова wait.
При чтении описания процедуры создания нового процесса может возникнуть вопрос: а зачем нужно копировать в новый процесс все данные процесса-родителя (например, код программы) и не слишком ли много времени займет копирование. Ответ на этот вопрос заключается в том, что при создании копии процесса его индивидуальные данные физически никуда не копируются. Вместо этого используется метод copy-on-write (копирование при записи): страницы данных обоих процессов особым образом помечаются, и только тогда, когда новый процесс пытается изменить содержимое какой-либо своей страницы, она дублируется.
