В этом совете мы поговорим о SELinux — одной из самых популярных систем управления доступом. Кроме SELinux существуют и другие системы управления доступом, например, GrSecurity и LIDS. Нужно отметить, что из этих систем самой строгой является SELinux. До сих пор эта система не была взломана, разумеется, при правильной настройке. Ясно, что все возможности SELinux мы не рассмотрим — SELinux вполне заслуживает отдельной книги.

Для начала давайте разберемся, зачем нам нужна система управления доступом как таковая? В Linux есть две крайности — два типа пользователей — обычный пользователь и администратор (root). Права обычных пользователей можно ограничить и с помощью штатных средств Linux. Если злоумышленник завладеет паролем администратора (как он это сделает — это уже другой вопрос), то он получит полную власть над системой. Но если на компьютере установлена система управления доступом, то она не позволит ему ничего сделать. Точнее, может он что-то и сделает, но только те операции, которые не причинят системе ощутимого вреда.

Вернемся к обычным пользователям. Их права доступа ограничиваются, как правило, только к файлам. Еще можно задать ограничение на использование системных ресурсов — дискового пространства (квоты), процессорного времени, установить максимальное число процессов. И все. Система управления доступом может запретить пользователю выполнять те действия, которые он не должен выполнять. Например, зачем пользователю, который зарегистрировался в системе только для чтения почты, возможность компиляции исходного кода или запуска фоновых демонов? Теперь все становится на свои места — мы понимаем, что SELinux нужна.

Кроме всего прочего, SELinux контролирует и права доступа к файлам. Например, система проверила права доступа файла и разрешила доступ файлу. Но потом принимается за работу SELinux. Если в настройках SELinux указано, что данный пользователь (или процесс) не имеет доступа к файлу, тогда SELinux запрещает доступ файлу. И в самом деле, зачем Web-серверу доступ каталогу /etc/selinux? Если же система запретила достук файлу (это первый эта— проверка прав доступа), тогда SELinux не задействуется.

Устанавливать SELinux мы будем не на "голый" компьютер, дабы не усложнять себе жизнь. Если вам нужна SELinux, установите дистрибутив Fedora Core или ASPLinux — в состав этих дистрибутивов SELinux входит по умолчанию.

Перейдите в каталог /etc/selinux. Вы найдете файл config, управляющий настройками самой SELinux, а также каталог targeted, в котором будут находиться конфигурационные файлы политики targeted. В нем будут три подкаталога — contexts, policy, users (контексты, политика, пользователи), а также файл booleans, в котором установлены некоторые булевые (логические) параметры. Пока эти файлы редактировать не нужно — оставьте все, как есть.

Что же в каталогах contexts, policy и users? Чтобы получить ответ на этот вопрос, нужно обратиться к скучной теории.

Начнем с базового понятия — понятия сущности. Сущность (identity) формирует часть контекста безопасности, задающего домены, в которые можно войти. То есть сущность определяет, что можно сделать. Не нужно путать сущность с идентификатором пользователя (UID). Они параллельно существуют в системе, но их смысл абсолютно разный. Обычно сущность представляется в системе так же, как и имя пользователя. Если в системе есть пользователь ppt и сущность ppt, выполнение команды su не изменяет сущность SELinux. Предположим, у нас есть пользователь ppt. Зарегистрируемся с его правами и выполним команду id (это команда SELinux), получим такой вывод:

context=ppt:user_r:user_t

Теперь введем команду su, наберем пароль root и снова введем команду id:

context=ppt:user_r:user_t

Мы получили тот же самый вывод. Контекст остался прежним и не заменился на контекст пользователя root. Правда, есть одно "но". Если сущности ppt разрешен достук роли sysadm_r (сейчас роль user_r) и пользователь выполнит команду newrole -г sysadm_r (изменит свою роль), а потом снова выполнит команду id, то получит вывод: context=ppt:sysadm_r:sysadm_t

Сущность осталось такой же, но роль и домен (второе и третье поля) изменились. Сущность определяет, какие роли и домены могут быть использованы.

Домен (domain) однозначно определяет привилегии процесса. Другими словами, домен представляет собой список того, что может сделать процесс, или, точнее, какие операции может выполнить процесс над разными типами. Примеры доменов: sysadm_t — домен администратора системы, user_t — домен для непривилегированных пользователей. Процесс ink выполняется в домене init_t, a named — в named_t.

Тип (type) задается для объекта и определяет достук этому объекту. Практически, тип — это то же самое, что и домен, но если домен относится к процессам, то тип— к файлам, каталогам, сокетам и т. п.

Роль (role) определяет список доменов, которые могут быть использованы. Домены, разрешенные для пользовательской роли, определяются в файлах политики. Если роль не имеет доступа к домену, то при попытке выполнения действия с доменом достубудет запрещен. Лучше всего это продемонстрировать на примере: если вам нужно разрешить непривилегированным пользователям (домен user_t) выполнять команду passwd, в конфигурационном файле нужно прописать: role user_r types user_passwd_t

Из команды видно, что пользователь с ролью user_r может входить в домен user_passwd_t, т. е. может выполнять команду passwd.

Контекст безопасности (security context) — это набор всех атрибутов, которые связаны с файлами, каталогами, процессами, ТСР-сокетами. Контекст безопасности состоит из сущности, роли, домена (или типа вместо домена). Команда id выводит текущий контекст безопасности.

Решение о переходе (transition) определяется контекстом безопасности, который будет назначен выполняемой операцией. Существует два вида переходов:

• переход домена процесса — используется при выполнении процесса определенного типа;
• переход типа файла — используется при создании файла в определенных каталогах.

Наконец, рассмотрим последнее понятие — понятие политики. Политика — это набор правил, контролирующих списки ролей, к которым у пользователя есть доступ, достуролей к доменам, достудоменов к типам.

Зарегистрируйтесь в системе как пользователь root и введите команду:

# system-config-securitylevel

В окне Настройка уровня безопасности перейдите на вкладку Настройка SELinux. По умолчанию SELinux обычно выключена. Для ее включения установите флажок Включено.

Окно Настройка уровня безопасности

Сразу после включения этого флажка вы увидите предупреждение о необходимости перемаркировать файловую систему правильными контекстами безопасности. Перемаркировка будет выполнена после перезагрузки системы. В этом же окне сообщается, что перемаркировка (аналог команды make relabel) может занять довольно много времени (зависит от размера файловой системы).

После этого обратите внимание на вкладку Настройка SELinux. На ней можно выбрать типолитики SELinux. Пока доступна только одна политика — targeted (целевая).

Теперь нажмите кнопку ОК и перезагрузите компьютер командой reboot. В процессе старта системы появится сообщение:

Warning — SELinux relabel is required ***

Это свидетельствует о том, что SELinux будет перемаркировывать файловую систему. Затем начнется загрузка — все как обычно. При входе в X Window на первую консоль будет выведено несколько не совсем обычных сообщений. Их формат мы разберем чуть позже. Первое, что хочется сделать, — это ввести команду id, чтобы просмотреть свой контекст безопасности:

context=root:system_r:hotplug_t

Роль system_r — это роль системы, которая выше роли sysadm_r.

Контекст безопасности пользователя root

Теперь самое время обратиться к конфигурационным файлам SELinux. Откройте файл /etc/selinux/config. В нем будут всего две директивы: SELINUX и SELINUXTYPE. Первая может принимать следующие значения:

• enforcing — применить политику безопасности SELinux;
• permissive — режим отладки — вместо запрета тех или иных операций SELinux будет просто выводить предупреждения;
• disabled — SELinux отключена.

Для второй директивы возможно два значения:

• targeted— будут защищены только целевые сетевые демоны (которые будут явно указаны);
• strict — полная защита.

Если вам нужна полная защита, установите пакет selinux-policy-strict. Данный пакет находится на первом компакт-диске ASPLinux 11. Со второго компакт-диска я бы посоветовал установить пакет selinux-doc. Дополнительная документация никогда не помешает.

Для аудита политик SELinux используется программа seaudit, но при запуске мы получаем сообщение, что не установлена политика по умолчанию. Самое интересное, что на дистрибутивных дисках я так и не нашел пакет policy, содержащий политику по умолчанию. Пришлось его взять из Интернета по адресу: ftp://rpmfind.netflinux/ASPLinux/i386/RPMS.10/policy-1.11.3-3.noarch.rpm.

Аудит политики

Роль имеет большое значение — у каждой роли свои полномочия, например, у роли sysadm_r полномочий намного больше, чем у user_r. Поэтому нужно знать, как можно изменить роль. Вообще-то в цели targeted, в которой мы сейчас работаем, роли пользователей особого интереса не представляют, поскольку осуществляется защита только выбранных сетевых демонов, но о команде newrole сказать все-таки нужно. Ее синтаксис следующий:

newrole -r роль

Например:

newrole -r sysadm_r

После этого нужно будет ввести пароль для сущности (пароль пользователя). Если нет прав доступа к указанной роли, вы увидите сообщение:

ppt: sysadm_r: sysadm__t is not a valid context

В этом случае указывается, что сущность ppt не имеет права доступа к роли sysadm_r.

Псевдофайловая система /selinux

При запуске системы с поддержкой SELinux в корне появится каталог /selinux — это псевдофайловая система SELinux (наподобие /ргос). С помощью этой файловой системы можно изменять некоторые параметры, например, режим работы SELinux. Как уже было отмечено, есть два режима работы — разрешающий (permissive) и принудительный (enforcing). В первом режиме SELinux только "ругается", а операционная система работает так же, как и обычная Linux-система без SELinux, а во втором применяются все настроенные политики. Отладочные сообщения в разрешающем режиме протоколируются в файл /var/log/messages. Для переключения в принудительный режим используется команда: echo "1" > /etc/selinux/enforce

Для перехода в разрешающий режим применяется команда:

echo "0" > /etc/selinux/enforce

Пользователи и SELinux

Лучше добавить всех необходимых пользователей в систему до включения SELinux, но бывают случаи, когда сделать это просто Невозможно (система работает продолжительное время, и учетные записи для всех пользователей заведены). Если SELinux уже активна, то для добавления нового пользователя нужно выполнить следующие команды:

становимся администратором:

$  SU

входим в роль sysadm_r:

# newrole -r sysadm_r

добавляем нового пользователя:

# useradd -с "New user" -m -d /home/newuser -g users -s /bin/bash -u

1005 newuser

# passwd newuser

Но этого мало. Нужно еще настроить роли пользователя. Для этого в файл /etc/selinux/users добавляем строку:

user newuser roles { user_r };

Этим мы назначаем пользователю newuser роль user_r. Если нужно, чтобы пользователь имел достук нескольким ролям, тогда укажите несколько ролей через пробел, например:

user setest roles { user_r sysadm_r };

Для активации изменений введите команду:

# make -С /etc/selinux load

Активация изменений займет некоторое время, по окончании этой операции вы увидите такие сообщения:

Success

touch tmp/load

make: Leaving directory '/usr/share/selinux/policy/current1

Следует отметить, что если пользователю нужен достутолько к роли user_r, это можно явно не указывать. Явно указывать нужно лишь в том случае, когда пользователю требуется изменить свой пароль самостоятельно.

Конфигуратор system-config-securitylevel

Теперь начинается самое интересное. Мы будем редактировать нашу политику. Сейчас у нас используется политика targeted, подразумевающая защиту только указанных вами сетевых демонов. Запустите конфигуратор system-config-securitylevel. На вкладке Настройка SELinux появится возможность (после активации SELinux) редактирования политики. Там все просто: приводится список служб и для каждой службы набор опций SELinux. Например, вот список опций для FTP:

• Выключить защиту SELinux для демона ftpd;
• Выключить защиту SELinux для демона inetd;
• Разрешить ftp читать/записывать файлы в домашних каталогах.
• А вот список привилегий пользователя (рис. 11.10):
• Позволить пользователям читать любые файлы по умолчанию;
• Разрешить пользователям запускать pppd соединения.

Протоколы SELinux

Рассмотрим пример типичного сообщения о нарушении доступа, которое можно обнаружить в /var/log/messages:

May 21 14:44:12 localhost kernel: audit(1148208252.610:29): avc: denied { read } for pid=2054 coram="bash" name=".baslx_profile" dev=hda6 ino=23695 scontext=root:system_r:hotplug_t tcontext=root:obj ect_r:user_home_t tclass=file

Строка "avc: denied" означает, что операция была запрещена. Далее следует идентификатор процесса, пытающегося выполнить операцию (for pid), имя процесса (comm), имя объекта (name), имя устройства (dev), номер иногда объекта (ino), контекст безопасности процесса (scontext), контекст безопасности объекта (tcontext) — в данном случае это файл ".bash_profile" и тицелевого объекта (tclass=f ile — тиобъекта — файл).

Set as favorite

Bookmark

Email This

Hits: 942

Комментарии (0)

RSS feed Comments

Написать комментарий

Имя

Электронный адрес

Вебсайт

Заголовок

Комментарий

smaller | bigger

Subscribe via email (Registered users only)

I have read and agree to the Terms of Usage.

Добавить комментарий