GRSecurity

Пакет GRSecurity представляет собой набор заплат для обеспечения безопасности ядра Linux версии 2.4. Цель проекта заключалась в создании безопасной и удобной в управлении ОС. GRSecurity предоставляет следующие возможности:

· запуск программ только в заданных директориях (Trusted Path Execution);

· случайное назначение номеров идентификаторов процессов и IP-дейтаграмм;

· усовершенствованная защита файлов – защищенные файлы могут быть скрытыми или с установленной защитой от изменений даже со стороны суперпользователя;

· защита процессов – ядро может отклонить отправку сигналов защищенным процессам. Процессы также могут быть скрытыми – каталог /proc не предоставит никакой информации об этом процессе;

· улучшенный контроль за правами доступа – применяется более эффективное назначение мандатов для предоставления привилегий, включая запрещение изменения мандатов пользователю с правами системного администратора;

· поддержка возможностей PaX (патч к ядру Linux, который предоставляет возможность настроить минимальные права доступа приложений к страницам памяти).

Все списки контроля доступа хранятся в удобных для чтения и изменения файлах.

PAM

Подключаемые модули аутентификации (Pluggable Authentication Module – PAM) не защитят систему после того, как она была взломана, но они могут помочь предотвратить сам взлом. Повышение безопасности достигается за счет чрезвычайно гибкой системы аутентификации.

PAM – это центральный механизм аутентификации всех служб, в том числе команды login, утилит дистанционной регистрации (telnet, rlogin, rsh, ftp), протокола PPP и команды su. Модули PAM позволяют ограничить доступ к приложениям и время доступа к системе, реализовать альтернативные схемы аутентификации, осуществить расширенную регистрацию событий. Они могут использоваться с любыми Unix-приложениями.

Рис. 13.1. Схема функционирования модулей PAM

В основе лежит ядро PAM (библиотеки, находящиеся в каталоге /lib), которое отвечает за загрузку необходимых модулей на основании конфигурационных файлов. Общая последовательность действий такова:

1. Приложение, например login, делает первичное обращение к ядру PAM.

2. Ядро PAM находит соответствующий конфигурационный файл в каталоге /etc/pam.d (или обращается к файлу /etc/pam.conf) и загружает из него список модулей, необходимых для обслуживания запроса.

3. После этого ядро PAM загружает модули в том порядке, в котором они перечислены в конфигурационном файле.

Некоторые модули организуют диалог с пользователем через вызывающее приложение. В ходе диалога обычно выдается приглашение на ввод различных параметров, например, пароля. В конечном итоге процедура аутентификации заканчивается успехом или неудачей. В случае неудачи выдается обобщенное сообщение об ошибке, которое, как правило, не раскрывает причину такого результата. Это защитная мера, чтобы злоумышленники не получили лишней информации. В то же время все модули оснащены средствами журнальной регистрации, что позволяет выявлять источники проблем и попытки нарушения прав доступа.

Конфигурирование PAM

Есть два конфигурационных параметра компиляции модулей PAM. Первый из них заставляет модуль использовать либо файл /etc/pam.conf, либо группу файлов в каталоге /etc/pam.d. Второй подключает оба конфигурационных механизма, причем записи, найденные в каталоге /etc/pam.d, имеют приоритет над записями файла /etc/pam.conf.

Формат файла /etc/pam.conf и файлов каталога /etc/pam.d неодинаков. В первом случае имеется начальное поле, определяющее тип службы, т.е. приложение, к которому относится данная запись. Во втором случае в каталоге находятся файлы, имя каждого из которых соответствует названию приложения. Соответственно, поле типа службы в этих файлах отсутствует.

Формат записей конфигурационного файла:

тип_модуля управляющий_флаг путь_к_модулю аргументы

Типы модулей PAM:

· auth – модуль данного типа заставляет приложение запросить у пользователя идентификационные данные, например пароль. Модуль может назначать пользователю права доступа и предоставлять привилегии;

· account – модуль данного типа проверяет различные параметры учетной записи пользователя, связанные, в частности, с устареванием пароля, ограничивая доступ в систему определенными периодами времени или определенными адресами подключения. Можно также задать ограничения на использование системных ресурсов;

· session – модуль данного типа используется для выполнения определенных функций до и после организации сеанса. Сюда входят задание переменных среды, журнальная регистрация и т.д.;

· password – модуль данного типа обычно объединяется в стек с модулем типа auth. Он отвечает за обновление пользовательского маркера аутентификации (как правило, пароля).

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

· required – чтобы пользователь получил доступ к службе, работа модуля должна завершиться успешно. Если модуль включен в стек, остальные модули тоже выполняются. Приложению не сообщается о том, какой из модулей потерпел неудачу;

· requisite – аналогично предыдущему, но в случае неудачи остальные модули в стеке не выполняются и приложению немедленно возвращается код ошибки;

· optional – это необязательный модуль, но если он один в стеке, то в случае неудачи приложению возвращается код ошибки;

· sufficient – если работа модуля завершается успешно, все остальные модули в стеке игнорируются, несмотря на связанные с ними управляющие флаги, и приложению возвращается код успешной аутентификации. Неудачное завершение работы не обязательно означает отказ от аутентификации, если только это не единственный модуль в стеке.

· [значение1=действие1

значение2=действие2] – использование данного синтаксиса позволяет более гибко управлять обработкой стека. Это называют флагом расширенного контроля.

Поле путь_к_модулю содержит полное имя модуля с указанием

пути доступа к нему.

Поле аргументы используется для указания флагов или опций, передаваемых модулю. Это необязательное поле. Есть несколько универсальных аргументов, поддерживаемых большинством модулей:

· debug – заставляет модуль передавать дополнительную информацию в систему Syslog. Точные действия зависят от конкретного модуля;

· audit – заставляет модуль передавать расширенную информацию в систему Syslog;

· no_warn – запрещает передавать приложению предупреждающие сообщения;

· use_first_pass – заставляет модуль использовать пароль, полученный от предыдущего модуля. Если аутентификация прошла неудачно, попытки получить другой пароль не предпринимаются. Этот аргумент предназначен для использования только с модулями типа auth и password;

· try_first_pass – аналогично предыдущему, но в случае неуспешной аутентификации у пользователя будет запрещен другой пароль. Этот аргумент предназначен для использования только с модулями типа auth и password;

· likeauth – заставляет модуль возвращать одинаковое значение независимо от того, проверяется или задается пароль (либо другие идентификационные данные).

Каждый файл в каталоге /etc/pam.d связан с определенным приложением, по имени которого он назван. Этот файл содержит список записей, в каждой из которых задается тип модуля, управляющий флаг, путь к модулю и дополнительные аргументы. Модули одного типа считаются объединенными в стек и выполняются в указанном порядке, если только управляющие флаги не предписывают досрочно прекратить выполнение. Работой службы или приложения управляет весь стек, а не один конкретный модуль. Необязательные аргументы используются для контроля работы модуля.

Контрольные вопросы

1. Какая модель безопасности реализована в SELinux?

2. Возможно ли с помощью SELinux запретить то, что запрещено через установку прав пользователей/групп?

3. Какой тип политики SELinux основан на модели Белла-Ла Падула?

4. Сравните SElinux и RSBAC.

5. Какие недостатки Unix-систем устраняет RSBAC?

6. Каковы отличительные особенности GRsecurity по сравнению с SELinux и RSBAC?

7. Почему возникла необходимость в появлении PAM?

8. Опишите схему функционирования модулей PAM.

9. Какие действия, связанные с аутентификацией, невозможно реализовать в модуле PAM?

10. Каким образом можно контролировать работу модулей PAM?

Лекция 14.

МОНИТОРИНГ СОБЫТИЙ БЕЗОПАСНОСТИ
СРЕДСТВАМИ UNIX-СИСТЕМ

Чтобы уменьшить вероятность несанкционированного доступа, нужно постоянно держать сервер под контролем. Для этого должен производиться регулярный мониторинг системы и поиск узких мест. Если взлом произошел, необходимо не только восстановить работу, но и предотвратить повторное вмешательство.

В Unix-системах существует множество журнальных файлов. Некоторые из них используются конкретными утилитами. Например, в файле /var/log/xferlog фиксируются записи об операциях по протоколу FTP. Журнальные файлы – важный источник информации о безопасности системы.

Поиск по сайту: