Учитывая, что я также разделяю проблему «SELinux складывает мой мозг пополам», я думаю, что могу помочь. Прежде всего, вы должны помнить разницу между дискреционным контролем доступа и обязательным контролем доступа. Вы также должны помнить, что пользовательское пространство определяет много вещей, но ядро заставляет их применять.
Во-первых, вот неполный список проблем пользовательского пространства по сравнению с пространством ядра:
- Пространство пользователя определяет действительный идентификатор пользователя, ядро создает процессы, принадлежащие этому идентификатору пользователя (число, а не имя)
- Пространство пользователя устанавливает права доступа и права доступа к файлу в файловой системе ext3 / 4, ядро обеспечивает доступ к этому файлу на основе файлового индекса и каждого последующего родительского каталога каталога
- Если два пользователя совместно используют один и тот же идентификатор пользователя в
/etc/passwd, ядро предоставит им одинаковые привилегии, поскольку принудительное выполнение выполняется с помощью числового идентификатора, а не текстового
- Пространство пользователя запрашивает сетевой сокет для другого хоста, ядро изолирует этот диалог от других в той же системе
- В SELinux пользовательское пространство определяет роли, логины и пользователей через
semanage, а ядро компилирует их в большой кэш доступа вектора (AVC), чтобы обеспечить принудительное управление доступом на основе ролей и обязательное управление доступом
- Также в SELinux администратор безопасности может использовать
semanage для определения минимального и максимального контекста безопасности. Если вы находитесь в конфигурации многоуровневой безопасности (MLS) и во время входа в систему пользователи выбирают какой-то контекст, то ядро измеряет это с помощью AVC, чтобы определить, разрешено ли это.
Что может помочь в этом, так это наличие многоуровневой конфигурации безопасности. Я взял урок на SELinux, и мы касались его около двух часов. Большинство людей не хотят туда идти. Когда-либо. Я немного разбирался в конфигурации MLS, поэтому я понимаю причину решения о кодировании, которое вы преследовали, но я согласен с тем, что использование MLS - довольно болезненный способ понять, как и почему PAM работает так, как работает.
Дискреционное управление доступом (DAC) - это место, где пользовательское пространство, особенно пользователи без полномочий root, могут определять, кто может получить доступ к данным, которыми они управляют, и каким образом. Подумайте, права доступа к файлу. Поскольку пользователи контролируют его, требуется тривиальное количество усилий, чтобы один пользователь мог видеть процессы и / или файлы, принадлежащие другому пользователю. Обычно нас это не волнует, потому что хороший администратор предполагает, что любой пользователь может поставить под угрозу весь блок, и поэтому всем пользователям доверяют одинаково. Это может быть очень мало доверия, но все еще некоторый уровень доверия.
Обязательный контроль доступа (MAC) - это место, где пользовательскому пространству нельзя доверять. Не все пользователи созданы равными. С точки зрения не MLS, рассмотрим случай, когда у вас есть веб-сервер и сервер базы данных на одном оборудовании (он никогда не переживет эффект Slashdot). Единственный раз, когда два процесса обмениваются данными, это по выделенному каналу соединения по TCP. В противном случае они не должны даже знать, что другой существует. Мы будем работать с ними в двух разных контекстах, и ядро будет обеспечивать разделение. Даже просмотр таблицы процессов или блуждание по жесткому диску в качестве пользователя root не приблизит вас, пока вы не измените контексты.
В конфигурации MLS я не могу сказать вам, сколько раз я пытался получить случайные комбинации чувствительности и контекста только для того, чтобы дать им отпор за выбор недопустимой комбинации. Это может быть очень неприятно, потому что для того, чтобы узнать, разрешено ли это или не разрешено, нужно много изучить существующую политику (/etc/selinux/ policy /src/policy/policy в Red Hat 5).
При строгой конфигурации я могу ясно видеть, почему все это излишне. И это просто потому, что SELinux является избыточным для простых ситуаций. У него есть и другие функции, которые частично его погашают, но главной из них является тонкодисперсное управление доступом, которое обеспечивает права доступа, установленные администратором. Одна из областей, в которой это используется чаще всего, заключается в ограничении сервисных демонов только их необходимым доступом. Настроить новый демон довольно болезненно, но он не позволяет банальным эксплойтам, таким как эксплойт совместно используемой библиотеки, продолжать, потому что рассматриваемый процесс может быть назначен на роль, которая не позволит ему запускать команды, не являющиеся демонами, такие как /bin/ls или оболочка. Эксплойты не приносят вам большой пользы в таких ситуациях.