Публичные сети (такие как сеть Интернет) – это довольно опасное место. Любой пользователь, у которого есть компьютер, подключенный к Интернету (даже если этот пользователь выходит в сеть на непродолжительное время), понимает угрозы, которые несут эти сети. Злоумышленники могут воспользоваться имеющимися в системе уязвимостями, чтобы получить неавторизованный доступ к важной информации, либо чтобы несанкционированно использовать ваш компьютер с целью рассылки спама или участия в атаках на более важные узлы сети (например, применять SYN-флад в качестве составной части DDoS-атак).
В DDoS-атаках (Distributed Denial of Service) используются многочисленные компьютеры, подключенные к Интернету (т.н. «компьютеры-зомби»). В результате такой атаки (при которой используется уязвимость трехэтапной процедуры установления соединения, используемой в протоколе TCP) на атакуемой системе происходит чрезмерное расходование ресурсов, что делает ее недоступной для пользователей. Для получения информации о протоколе SCTP (Stream Control Transmission Protocol), в котором исключена возможность такой атаки благодаря использованию четырехэтапной процедуры установления соединения с применением cookies, обратитесь к разделу «Ресурсы».
GNU/Linux является очень надежной, но в то же время динамично развивающейся операционной системой. В результате вносимых изменений в ней могут появиться уязвимости, которыми могут воспользоваться злоумышленники. Несмотря на то, что значительное внимание уделяется предотвращению несанкционированного доступа к системе, что будет, если все-таки такой доступ произойдет?
В этой статье рассматривается общая архитектура SELinux, а также описываются основные принципы, на которых построена данная операционная система. Полный обзор SELinux мог бы стать темой для написания целой книги (пример такой книги можно найти в разделе «Ресурсы»), поэтому в данной статье дается только основная информация о том, почему ОС SELinux действительно так важна, и как реализуются механизмы, заложенные в ней.
Происхождение SELinux
SELinux – это правительственная и промышленная разработка. В создании SELinux приняли участие NSA, Network Associates, Tresys и многие другие организации. Хотя изначально NSA представило SELinux в виде набора исправлений, теперь SELinux является основополагающим элементом ядра Linux версии 2.6.
В большинстве операционных систем имеются средства управления доступом, которые определяют, может ли определенный объект (пользователь или программа) получить доступ к определенному ресурсу. В системах UNIX® применяется разграничительный контроль доступа (discretionary access control, DAC). Этот метод позволяет ограничить доступ к объектам на основе групп, к которым они принадлежат. Например, в GNU/Linux для каждого файла определены владелец, группа, а также указаны права доступа к этому файлу. Правами доступа определяется, кто может получить доступ к файлу, кто может открыть его для чтения, кто может внести в него изменения, кто может запустить этот файл на выполнение. Права доступа определены для трех категорий: пользователь (владелец файла), группа (все пользователи, которые являются членами группы) и другие (все пользователи, которые не являются ни владельцем файла, ни членами группы).
Такое разграничение прав доступа может привести к возникновению ряда проблем из-за того, что программа, в которой может быть обнаружена уязвимость, наследует все права доступа пользователя. Следовательно, она может выполнять действия с тем же уровнем привилегий, какой есть у пользователя (что нежелательно). Вместо того чтобы определять ограничения подобным образом, более безопасно использовать принцип наименьшего уровня привилегий (principle of least privilege), согласно которому программы могут делать только то, что им необходимо для выполнения своих задач, и не более того. Например, если у вас есть программа, задача которой состоит в приеме запросов через сокеты, при этом ей не нужно иметь доступ к файловой системе, то такая программа будет иметь возможность только прослушивать определенный сокет и не будет иметь доступа к файловой системе. Таким образом, даже если в программе будет обнаружена уязвимость, то возможности доступа данной программы будет жестко ограничены. Такой тип контроля называется принудительным управлением доступом (mandatory access control, MAC).
Другим методом управления доступом является управление доступом на основе ролей (role-based access control, RBAC). При использовании RBAC права доступа предоставляются на основе ролей, выдаваемых системой безопасности. Отличие концепции ролей от традиционных групп состоит в том, что группа представляет одного или нескольких пользователей, в то время как роль, хотя она также может быть применена к нескольким пользователям, представляет совокупность полномочий на выполнение определенных действий.
SELinux добавляет в операционную систему GNU/Linux поддержку как MAC, так и RBAC. В следующем разделе рассказывается о реализации SELinux, а также о том, как было прозрачным образом произведено усиление защиты ядра Linux.
Обеспечение безопасности в Linux
Когда на ранней стадии своего развития SELinux еще являлась набором исправлений, она предоставляла свою собственную инфраструктуру безопасности. Это вызывало определенные сложности, поскольку ограничивало GNU/Linux жесткими рамками архитектуры, основанной на одном методе управления доступом. Вместо принятия такого подхода ядро Linux унаследовало общую инфраструктуру, в которой политика и усиление безопасности были разделены. Такого разделения удалось достичь благодаря использованию модуля LSM (Linux Security Module). Общесистемная инфраструктура безопасности, предоставляемая модулем LSM, такова, что позволяет реализовывать модели безопасности в виде загружаемых модулей ядра (рисунок 1).
Рисунок 1. В SELinux усиление безопасности происходит независимо от применяемых политик
Перед доступом к внутренним объектам производится изменение кода ядра. Это осуществляется с помощью специальной функции усиления безопасности (перехватчика вызовов системных функций ОС), посредством которой применяется политика безопасности. Данная функция выполняет проверку возможности выполнения определенной операции на основании заранее определенных политик. Функции безопасности хранятся в структуре безопасных операций, охватывающей основные операции, защиту которых необходимо обеспечить. Например, функция security_socket_create (security_ops->socket_create) осуществляет проверку прав доступа перед созданием нового сокета и проверяет семейство протоколов, тип, протокол, а также то, на каком именно уровне (уровне ядра или уровне пользователя) создается сокет. В листинге 1 показан фрагмент кода из файла ./linux/net/socket.c, с помощью которого осуществляется создание сокета.
Листинг 1. Код ядра, с помощью которого осуществляется создание сокета
|
Функция security_socket_create определена в файле ./linux/include/linux/security.h. Она обеспечивает косвенный вызов из функции security_socket_create в функцию, динамически подставляемую в структуру security_ops (листинг 2).
Листинг 2. Косвенный вызов для проверки создания сокета
|
Функция в структуре security_ops подставляется модулем безопасности. В этом случае функции-перехватчики определены в загружаемом модуле ядра SELinux. Все вызовы SELinux определены в файле функций-перехватчиков, который используется на завершающей стадии перенаправления из функции ядра в динамический вызов для конкретного модуля безопасности (см. фрагмент кода, представленный в листинге 3, взятый из файла .../linux/security/selinux/hooks.c).
Листинг 3. Проверка создания сокета в SELinux
|
В основе листинга 3 находится вызов, который используется для проверки того, разрешено ли выполнять текущую операцию в рамках текущей задачи (как определено записью current->security, где запись current соответствует выполняемой в данный момент задаче). В кэше векторов доступа (Access Vector Cache, AVC) хранятся предыдущие решения SELinux (это сделано для улучшения производительности). Этот вызов содержит в себе идентификатор безопасности источника (source security identifier, sid), класс безопасности (составленный из подробной информации о запрашиваемых операциях), вызов особого сокета и дополнительные вспомогательные данные аудита. Если необходимое решение в кэше не находится, то для его получения производится вызов серверу безопасности (процесс показан на рисунке 2).
Рисунок 2. Многоуровневый процесс обеспечения безопасности Linux
Обратные функции-перехватчики, инициализированные в security_ops, динамически определяются в качестве загружаемых модулей ядра (через register_security())), но если модуль безопасности не загружен (см. файл ./linux/security/dummy.c), они содержат только пустые функции-заглушки. Эти функции-заглушки реализуют стандартную политику DAC в Linux. Обратные функции-перехватчики присутствуют везде, где в целях безопасности необходимо наличие объектов-посредников. Их присутствие необходимо при управлении задачами (создание, сигнализация, ожидание), загрузке программ (execve), управлении файловой системой (перехватчики суперблоков, inode и файлов), при межпроцессном вызове процедур (IPC) (очередь сообщений, разделяемая память и семафорные операции), при использовании перехватчиков модуля (вставка и удаление) и перехватчиков сети (изолирующие сокеты, netlink, сетевые устройства и другие интерфейсы протоколов). Получить более подробную информацию о различных перехватчиках вы можете с помощью ссылок из раздела «Ресурсы», либо путем просмотра файла security.h.
Управление политиками в SELinux выходит за рамки рассмотрения данной статьи, но вы можете получить дополнительную информацию о настройке SELinux в разделе «Ресурсы».
ОС SELinux является одной из наиболее всесторонне защищенных сред, доступный на сегодняшний день, но, безусловно, не единственной. В данном разделе описываются некоторые другие подходы к созданию защищенных систем.
AppArmor, изначально разработанный Immunix, а ныне поддерживаемый Novell, является альтернативой SELinux, при этом в нем также используется инфраструктура модуля LSM (Linux Security Module). Поскольку SELinux и AppArmor используют одну и ту же инфраструктуру, они являются взаимозаменяемыми. Причиной создания AppArmor стало то, что SELinux казался слишком сложным для использования обычными пользователями. В AppArmor имеется полностью настраиваемая MAC-модель и режим обучения, при котором для каждой программы можно создать соответствующий профиль на основе выполняемых этой программой действий.
Недостатком SELinux является необходимость наличия файловой системы, поддерживающей дополнительные атрибуты, в то время как AppArmor не зависит от типа файловой системы. AppArmor имеется в SUSE, OpenSUSE, а теперь и в Ubuntu's Gutsy Gibbon.
Solaris 10 (ранее Trusted Solaris)
Операционная система Solaris 10 обеспечивает принудительное управление доступом с помощью своего компонента Trusted Extensions, улучшающего защиту. Улучшение защиты в Solaris обеспечивается как для MAC, так и для RBAC путем добавления меток чувствительности ко всем объектам, в результате чего вы получаете контроль над устройствами, файлами, сетевым доступом и даже над службами управления окнами. Преимуществом RBAC в Solaris 10 является минимальное количество действий, для выполнения которых требуются привилегии пользователя root. Это достигается благодаря наличию возможности четко разграничивать полномочия для выполнения определенных задач, связных с администрированием.
TrustedBSD – это рабочий проект, предназначенный для разработки расширений надежной операционной системы, предназначенных для использования с ОС FreeBSD. Он включает в себя принудительное управление доступом, построенное на базе архитектуры безопасности Flux Advanced Security Kernel (Flask), включающий в себя усиление типа и многоуровневую защиту (multilevel security, MLS), подключаемые в виде дополнительных модулей. TrustedBSD также содержит в себе модуль BSM (Basic Security Module), реализующий функции аудита из операционной системы Apple Darwin. Модуль BSM - продукт с открытым исходным кодом, изначально представленный Sun. BSM представляет собой API аудита и формат файлов, поддерживающие обобщенную обработку контрольного следа. Trusted BSD также формирует инфраструктуру, используемую Security Enhanced Darwin (SEDarwin).
Виртуализация операционных систем
Еще одним вариантом усиления безопасности операционных систем является технология виртуализации операционных систем (также известная как виртуальные частные серверы). В этом подходе одна операционная система содержит множество изолированных (в плане функциональных возможностей) объектов пространства пользователя. Виртуализация операционных систем также ограничивает возможности приложений, работающих в рамках изолированного пространства пользователя. Например, объект пространства пользователя не имеет возможности изменять ядро (загружать или удалять модули ядра), монтировать и демонтировать файловые системы. Изменение параметров ядра (например, через файловую систему proc) также не разрешено. Не разрешено все, что может изменить среду других объектов пользователя.
Многие операционные системы поддерживают виртуализацию. GNU/Linux поддерживает VServer, Parallels Viruozzo Containers и OpenVZ. В других операционных системах имеются контейнеры (Solaris) и «тюрьмы» (BSD). В Linux-VServer каждый индивидуальный объект пространства пользователя называется контекстом безопасности. Для каждого объекта частного сервера запускается новый процесс init в рамках контекста безопасности. Больше узнать о виртуализации операционных систем и других методах виртуализации вы можете с помощью ссылок, приведенных в разделе «Ресурсы».
Принудительное управление доступом и управление доступом на основе ролей являются относительно новыми методами управления доступом для ядра Linux. С введением инфраструктуры LSM, несомненно, станут доступны новые модули безопасности. В дополнение к улучшению инфраструктуры станет возможным объединять модули безопасности в стек, что позволит нескольким модулям безопасности работать совместно, обеспечивая всестороннюю защиту Linux. Дальнейшие исследования обеспечения безопасности операционных систем позволят создать новые методы управления доступом. Для получения более подробного представления о текущих предложениях LSM и SELinux изучите статьи и другие материалы, ссылки на которые представлены в разделе «Ресурсы».
Комментариев нет:
Отправить комментарий