Поддержи Openmeetings

пятница, 6 июня 2014 г.

Основные понятия SELinux

SELinux (Security-Enhanced Linux, Linux с улучшенной безопасностью) — реализация системы принудительного контроля доступа, которая может работать параллельно с классической дискреционной системой контроля доступа. Входит в стандартное ядро операционной системы Linux, начиная с версии 2.6. SELinux, как и другие реализации моделей безопасности, подключается к ядру посредством фреймфорка LSM (Linux Security Modules), который обеспечивает перехват ключевых системных вызовов системой безопасности. Для функционирования SELinux требуется поддержка со стороны файловой системы. Поддержка новых функций ядра обеспечивается модифицированными версиями некоторых утилит (например, ps, ls, cp, id).

Мотивацией разработки SELinux послужило то, что стандартная модель безопасности Linux имеет недостаточную «разрешающую способность». Более конкретно это выражается в следующих ограничениях.

  • В рамках дискреционной системы контроля доступа, у пользователей сохраняется возможность распоряжаться правами доступа к объектам, владельцами которых они являются.
  • Многие права доступа предоставляются по принципу «либо всем, либо только одному». Поэтому пользователи и процессы часто вынуждены действовать от имени суперпользователя со всеми вытекающими полномочиями, для выполнения задач, требующих гораздо меньших прав. В ядрах Linux, начиная с версии 2.2, добавлено разграничение привилегированного доступа к ресурсам на основе capabilities.
  • Отсутствует разграничение прав доступа к некоторым важным объектам системы. Например, в старых версиях ядра Linux от имени любой пользовательской учетной записи можно запустить сервер TCP/IP (если только соответствующий порт уже не занят другим приложением). Для большинства пользователей подобная функциональность избыточна и предоставляет возможность несанкционированного доступа к ресурсам.

В SELinux права доступа определяются системой специально определенных политик, которые работают на уровне системных вызовов. Политики описываются при помощи языка описания правил доступа конкретных субъектов к конкретным ресурсам. Политики SELinux действуют после применения классической модели безопасности Linux. Иными словами, политики SELinux не могут разрешить то, что запрещено дискреционной моделью.

В состав дистрибутива входят готовые политики, которые, в частности, разделяют системные и пользовательские объекты и субъекты доступа. Система управления доступом допускает дальнейшее конфигурирование на основе ролей и уровней доступа, например, «для служебного пользования», «секретно», «совершенно секретно», «особой важности».

Режимы работы SELinux

Для того, чтобы узнать, в каком режиме работает система безопасности SELinux, используют команду getenforce, которая возвращает значение Enforcing, Permissive, или Disabled.

В режиме принудительном (enforcing) режиме политики SELinux разграничивают доступ к объектам. В разрешительном режиме (permissive) политики SELinux не ограничивают действия, но запреты журналируются. Или можно просто отключить SELinux (режим disabled).

Основные понятия

В данном разделе рассматриваются основные понятия системы безопасности SELinux.

Идентификатор пользователя

Идентификатор пользователя (uid) — положительное целое число, которому в операционной системе однозначно соответствует пользователь.

Это число выбирается автоматически при регистрации учётной записи. Суперпользователь имеет uid, равный нулю (0). uid от 1 до 100 резервируются под системные нужды (1–499 в Red Hat, 1–999 в Debian).

Установка ID во время выполнения

Установка ID пользователя во время выполнения (set user ID upon execution, setuid) и установка ID группы во время выполнения (set group ID upon execution, setgid) являются флагами прав доступа в Unix, которые разрешают пользователям запускать исполняемые файлы с правами владельца или группы исполняемого файла.

Capabilities

Capabilities — средства для управления привилегиями, которые в традиционных Unix-подобных системах были доступны только процессам, запущенным с правами root (uid = 0), или процессам с установленным SUID-битом. Этот механизм позволяет дать процессу права на выполнение каких-либо действий, недоступных обычному пользователю (например, изменение системного времени, прямой доступ к аппаратуре, использование зарезервированных портов TCP/UDP (< 1024), блокировка страниц в физической памяти), но в то же время не предоставлять этому процессу полный набор прав root. Например, процесс ntpd выполняется с правами псевдопользователя (и в chroot), но благодаря наличию привилегии CAP_SYS_TIME имеет возможность модифицировать системное время.

Сущность

Сущность (SELinux identity, SELinux user) — часть контекста безопасности, который задает домены, в которые можно войти. Сущность — это не то же, что и традиционный идентификатор пользователя (uid). Сущность в SELinux может иметь одинаковое символьное представление с именем пользователя, но это разные понятия.

Выполнение команды su не меняет сущности пользователя в SELinux. Например, если непривилегированный пользователь aaf выполняет команду id (в SELinux), то он видит свой контекст безопасности:

context=aaf:user_r:user_t

Часть контекста aaf — сущность. Если пользователь aaf выполняет su, чтобы получить привилегии пользователя root, и затем вызывает id, он увидит, что контекст всё ещё тот же:

context=aaf:user_r:user_t

Если сущности aaf разрешается доступ к роли sysadm_r, и пользователь запустит новую оболочку (введя команду newrole -r sysadm_r) от лица роли sysadm_r, то увидит следующее:

context=aaf:sysadm_r:sysadm_t

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

Домен

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

Каждый процесс выполняется в домене. Домен однозначно определяет права процесса, или какие действия процесс может выполнять над объектами контролируемого доступа (над типами объектов).

В качестве примеров доменов можно привести sysadm_t — домен системного администрирования, и user_t — общий домен для непривилегированных пользователей. Процесс init выполняется в домене init_t, named — в домене named_t.

Когда вы смотрите контекст безопасности процесса (ps -ef --context), последнее поле — это домен. Например, если выполняется программа passwd, домен равен passwd_t.

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

В стандартной модели безопасности Linux, если пользователь root выполнил для своей программы команду chmod 4777 и установил атрибут setuid, то любой другой пользователь сможет выполнить эту программу с полномочиями суперпользователя. Если программа имеет уязвимость, позволяющую запускать другие процессы, то любой пользователь получает полный контроль над системой.

Тип

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

Объекты, соответствующие ресурсам, такие как файлы, каталоги, сокеты, имеют типы. Например, при выполнении команды ls --context для файла из домашней директории обычного пользователя, последнее поле представляет тип home_t.

Учитывая, что в Linux каждому процессу соответствует виртуальный файл в директории /proc, между типами и доменами есть прямая связь. Типы файлов в директории /proc равны доменам соответствующих процессов. Например, вызов команды ls --context /proc выдаёт следующую информацию для процесса init:

dr-xr-xr-x  root     root     system_u:system_r:init_t         1

Контекст безопасности говорит нам о том, что этот файл имеет тип init_t. С помощью команды ps ax --context | grep init можно убедиться, что процесс init действительно выполняется в домене init_t.

Важным отличием типов от доменов является то, что команды изменения идентификатора безопасности chsid и изменения контекста chcon не работают на файловой системе /proc. Метки процессов могут изменяться только в процессе перехода.

Роль

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

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

role user_r types passwd_t

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

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

Контекст безопасности

Контекст безопасности (метка) — совокупность всех атрибутов, которые связаны с объектами (файлами, каталогами, процессами, сокетами) и субъектами. Контекст безопасности состоит из сущности, роли и домена или типа. Пользователь может увидеть свой собственный контекст безопасности, выполнив команду id в SELinux.

Политика безопасности

Политика безопасности — это набор заданных правил, который регулирует взаимодействие ролей, доменов и типов.

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

Переход

Контекст нового процесса определяется в зависимости от политик безопасности и текущего контекста. Изменение контекста процесса называется переходом (transition), при этом меняется домен контекста.

Переход домена процесса можно продемонстрировать на примере запуска ssh из-под обычного пользователя (из домена user_t). Если ssh запускается пользователем aaf, то ps ax --context | grep ssh покажет контекст aaf:user_r:ssh_t. В связи с тем, что программа ssh имеет тип ssh_exec_t, выполняется попытка перехода в домен ssh_t. Так как роль user_r имеет право доступа в домен ssh_t, то переход завершается успешно.

Второй тип перехода — это переход типа файла, который применяется при создании файла. Контекст безопасности создаваемого файла зависит от домена процесса, который создал файл. По умолчанию, новый файл или каталог наследует тип от родительского каталога. Например, если пользователь aaf создаёт файл test в своем домашнем каталоге, то ls --context test выдаст:

-rw-r--r--  aaf     aaf     aaf:object_r:home_t        test

Однако можно задать иную политику в определённых каталогах. Например, при создании пользователем файла в каталоге /tmp происходит переход в тип tmp_t и новый файл помечается соответствующим образом. Если пользователь aaf создаёт файл в каталоге /tmp с именем tmptest и выполняет команду ls --context /tmp/tmptest, то результат будет такой:

-rw-r--r--  aaf     aaf     aaf:object_r:tmp_t       /tmp/tmptest

В первом примере контекст безопасности включал тип home_t, который является типом по умолчанию для домашнего каталога непривилегированного пользователя с ролью user_r. Во втором примере тип равен tmp_t — это тип по умолчанию для файлов, созданных процессами домена user_t в каталоге типа tmp_t.

Комментариев нет :

Отправить комментарий