Пару недель назад в новостях промелькнуло сообщение о том, что Red Hat Enterprise Linux на серверах IBM получил уровень сертификации по безопасности EAL4 Augmented with ALC_FLR.3. Это наивысший уровень сертификации, который когда-либо достигался операционной системой. Кроме RHEL5 эта планка достигнута лишь Trusted Solaris. Такой уровень как правило не нужен при внедрениях в коммерческих организациях, но он открыл дорогу для участия в проектах связанных с правительственными и военными организациями США. До этого другие дистрибутивы Linux уже имели подтвержденный уровень доверия EAL4, но без сертификации Labeled Security Protection Profile (LSPP).
Что важно нам, «простым смертным», - нет необходимости платить никому ни копейки для того, чтобы получить на своей машине столь же высокий уровень защиты, какой требуется в военных ведомствах. Как известно, Enterprise Linux строится на кодовой базе Open Source проекта Fedora (прежнее название Fedora Core). Забавно, что в RHEL5 Server более 300 пакетов даже не пересобирались специально под Enterprise Linux – это видно по тегу fc6 в имени пакета (в RHEL5 тег - el5). Так что в ряде случаев общий не только код, но и сами «бинарники». Fedora же совершенно бесплатно доступна для скачивания. Сравнение Enterprise Linux и Fedora приведено здесь.
Итак, каким же образом обеспечивается соответствие столь высокому критерию безопасности? В немалой степени это стало возможным благодаря SELinux (Security-Enhanced Linux) - реализации системы мандатного контроля доступа (MAC), которая может работать (и работает по умолчанию) параллельно с классической дискреционной системой контроля доступа (DAC).
Оставаясь в рамках DAC, мы имеем фундаментальное ограничение в плане разделения доступа пользователей к ресурсам – доступ к ресурсам основывается на правах доступа пользователя. Это классические права rwx на трех уровнях – владелец, группа-владелец и остальные. Плюс к этому, POSIX ACL, которые лишь расширяют число уровней, на которых можно определить права, но не более.
Таким образом, любое приложение, запущенное с правами usera, теоретически может сделать все что угодно со всеми данными, к которым имеет доступ usera. И не важно, например, что данное приложение – это почтовая программа, которой нужно иметь доступ только к письмам usera. Эта программа будет иметь доступ и, например, к видеофайлам usera, и к картинкам usera. И мало того, что сама программа имеет доступ, но она же может и все эти данные сделать доступными остальным. Все становиться гораздо хуже, когда usera имеет UID=0 (то есть это root). Мы утыкаемся в классическую «проблему суперпользователя». В данном случае мы получаем всего лишь два уровня доступа: root и обыкновенные пользователи. Иными словами, становиться невозможным реализовать доступ с использованием минимально необходимых привилегий.
В MAC же права доступа определяются самой системой при помощи специально определенных политик. Если же говорить конкретно о рассматриваемой реализации – SELinux, то такие политики работают на уровне системных вызовов и применяются самим ядром (но можно реализовать и на уровне приложения). SELinux изначально был разработан АНБ США, а в настоящий момент является Open Source-проектом и входит в стандартное «ванильное» ядро Linux. Коммерческая поддержка доступна уже более двух лет в составе RHEL4.
SELinux действует после классической модели безопасности Unix. Иными словами, через SELinux нельзя разрешить то, что запрещено через права доступа пользователей/групп. Политики описываются при помощи специального гибкого языка описания правил доступа. В большинстве случаев правила SELinux «прозрачны» для приложений, и не требуется никакой их модификации. В состав Fedora/RHEL входят готовые политики, в которых права могут определяться на основе совпадения типов процесса (субъекта) и файла (объекта) – это основной механизм SELinux. Две других формы контроля доступа – доступ на основе ролей и на основе многоуровневой системы безопасности (например, ДСП, секретно, совершенно секретно).
Самый простой для работы и поддержки с точки зрения ИТ службы предприятия тип политики - так называемая «целевая» политика, разработанная в рамках проекта Fedora. Эта политика устанавливается и включается по умолчанию и в RHEL4, и в RHEL5 и является единственной, поддерживаемой Red Hat в составе стандартных контрактов поддержки, политикой. В рамках политики описано более 200 процессов, которые могут выполняться в RHEL5 (в RHEL4 описано намного меньше, в том числе httpd,squid,pegasus,Mailman,Named, dhcpd,mysqld, nscd,ntpd,portmap,postgresql,snmpd,syslogd,winbindd). Все, что не описано «целевой» политикой, выполняется в домене (с типом) unconfined_t. Процессы, работающие в этом домене, не защищаются SELinux. Таким образом, все сторонние пользовательские приложения будут без всяких проблем работать в системе с «целевой» политикой в рамках классических разрешений DAC.
Кроме «целевой» политики, в состав дистрибутива входит политика с многоуровневой моделью безопасности (с поддержкой модели Bell LaPadula). Коммерческая поддержка этой политики доступна в RHEL5 со специальной лицензией и только для серверных систем с ограниченным числом установленных пакетов и без X Window System. Именно системы с данной политикой теперь имеют сертификацию EAL4+/LSPP.
Третий вариант политики - «строгий». Тут действует принцип «что не разрешено, то запрещено». Политика основывается на Reference Policy от компании Tresys. Данная политика не имеет коммерческой поддержки в RHEL.
Что важно нам, «простым смертным», - нет необходимости платить никому ни копейки для того, чтобы получить на своей машине столь же высокий уровень защиты, какой требуется в военных ведомствах. Как известно, Enterprise Linux строится на кодовой базе Open Source проекта Fedora (прежнее название Fedora Core). Забавно, что в RHEL5 Server более 300 пакетов даже не пересобирались специально под Enterprise Linux – это видно по тегу fc6 в имени пакета (в RHEL5 тег - el5). Так что в ряде случаев общий не только код, но и сами «бинарники». Fedora же совершенно бесплатно доступна для скачивания. Сравнение Enterprise Linux и Fedora приведено здесь.
Итак, каким же образом обеспечивается соответствие столь высокому критерию безопасности? В немалой степени это стало возможным благодаря SELinux (Security-Enhanced Linux) - реализации системы мандатного контроля доступа (MAC), которая может работать (и работает по умолчанию) параллельно с классической дискреционной системой контроля доступа (DAC).
Оставаясь в рамках DAC, мы имеем фундаментальное ограничение в плане разделения доступа пользователей к ресурсам – доступ к ресурсам основывается на правах доступа пользователя. Это классические права rwx на трех уровнях – владелец, группа-владелец и остальные. Плюс к этому, POSIX ACL, которые лишь расширяют число уровней, на которых можно определить права, но не более.
Таким образом, любое приложение, запущенное с правами usera, теоретически может сделать все что угодно со всеми данными, к которым имеет доступ usera. И не важно, например, что данное приложение – это почтовая программа, которой нужно иметь доступ только к письмам usera. Эта программа будет иметь доступ и, например, к видеофайлам usera, и к картинкам usera. И мало того, что сама программа имеет доступ, но она же может и все эти данные сделать доступными остальным. Все становиться гораздо хуже, когда usera имеет UID=0 (то есть это root). Мы утыкаемся в классическую «проблему суперпользователя». В данном случае мы получаем всего лишь два уровня доступа: root и обыкновенные пользователи. Иными словами, становиться невозможным реализовать доступ с использованием минимально необходимых привилегий.
В MAC же права доступа определяются самой системой при помощи специально определенных политик. Если же говорить конкретно о рассматриваемой реализации – SELinux, то такие политики работают на уровне системных вызовов и применяются самим ядром (но можно реализовать и на уровне приложения). SELinux изначально был разработан АНБ США, а в настоящий момент является Open Source-проектом и входит в стандартное «ванильное» ядро Linux. Коммерческая поддержка доступна уже более двух лет в составе RHEL4.
SELinux действует после классической модели безопасности Unix. Иными словами, через SELinux нельзя разрешить то, что запрещено через права доступа пользователей/групп. Политики описываются при помощи специального гибкого языка описания правил доступа. В большинстве случаев правила SELinux «прозрачны» для приложений, и не требуется никакой их модификации. В состав Fedora/RHEL входят готовые политики, в которых права могут определяться на основе совпадения типов процесса (субъекта) и файла (объекта) – это основной механизм SELinux. Две других формы контроля доступа – доступ на основе ролей и на основе многоуровневой системы безопасности (например, ДСП, секретно, совершенно секретно).
Самый простой для работы и поддержки с точки зрения ИТ службы предприятия тип политики - так называемая «целевая» политика, разработанная в рамках проекта Fedora. Эта политика устанавливается и включается по умолчанию и в RHEL4, и в RHEL5 и является единственной, поддерживаемой Red Hat в составе стандартных контрактов поддержки, политикой. В рамках политики описано более 200 процессов, которые могут выполняться в RHEL5 (в RHEL4 описано намного меньше, в том числе httpd,squid,pegasus,Mailman,Named, dhcpd,mysqld, nscd,ntpd,portmap,postgresql,snmpd,syslogd,winbindd). Все, что не описано «целевой» политикой, выполняется в домене (с типом) unconfined_t. Процессы, работающие в этом домене, не защищаются SELinux. Таким образом, все сторонние пользовательские приложения будут без всяких проблем работать в системе с «целевой» политикой в рамках классических разрешений DAC.
Кроме «целевой» политики, в состав дистрибутива входит политика с многоуровневой моделью безопасности (с поддержкой модели Bell LaPadula). Коммерческая поддержка этой политики доступна в RHEL5 со специальной лицензией и только для серверных систем с ограниченным числом установленных пакетов и без X Window System. Именно системы с данной политикой теперь имеют сертификацию EAL4+/LSPP.
Третий вариант политики - «строгий». Тут действует принцип «что не разрешено, то запрещено». Политика основывается на Reference Policy от компании Tresys. Данная политика не имеет коммерческой поддержки в RHEL.
Графическая утилита настройки system-config-selinuxFedora и RHEL, безусловно, не единственные дистрибутивы, поддерживающие SELinux. Достаточно вспомнить Debian и Hardened Gentoo. Но, на мой взгляд, именно в Fedora/RHEL воспользоваться преимуществом мандатного контроля доступа наиболее просто «из коробки». Для удобства управления в состав дистрибутива входят графические утилиты управления и мониторинга от Red Hat и Tresys.
В дальнейших постах блога я предполагаю более подробно коснуться SELinux и привести ссылки на ресурсы в Интернет.
Update. Продолжение разговора о SELinux:
Часть 2.1. SELinux. MLS и MCS: что с чем едят. MLS.
Часть 2.2. SELinux. MLS и MCS: что с чем едят. MCS
