Как ограничивается диапазон SELinux MLS при входе в систему?

Question

Я пытаюсь понять, какая логика определяет, может ли пользователь войти в систему с определенным уровнем чувствительности MLS.Сначала я подозревал, что pam_selinux.so читает файл /etc/selinux/.../seusers, чтобы понять, какой пользователь привязан к какому пользователю, а затем ограничивает пользователя чувствительностью, равной или меньшей, чем высокий компонент диапазона MLS.

Однако, покопавшись в исходном коде, я обнаружил, что после запроса пользователя, хочет ли он изменить контекст безопасности по сравнению с контекстом по умолчанию, pam_selinux проверяет, подходят ли новые метки MLS, вызывая политику ядра.

Следующий код находится в файлах groups/pam_selinux/pam_selinux.c из пакета Ubuntu libpam-modules 1.1.1-4ubuntu2.

static int mls_range_allowed(pam_handle_t *pamh, security_context_t src, security_context_t dst, int debug)
{
  struct av_decision avd;
  int retval;
  unsigned int bit = CONTEXT__CONTAINS;
  context_t src_context = context_new (src);
  context_t dst_context = context_new (dst);
  context_range_set(dst_context, context_range_get(src_context));
  if (debug)
    pam_syslog(pamh, LOG_NOTICE, "Checking if %s mls range valid for  %s", dst, context_str(dst_context));

  retval = security_compute_av(context_str(dst_context), dst, SECCLASS_CONTEXT, bit, &avd);
  context_free(src_context);
  context_free(dst_context);
  if (retval || ((bit & avd.allowed) != bit))
    return 0;

  return 1;
}

Мне кажется, что эта проверка на самом деле проверяется в политике ядра, что видно из вызова Security_compute_av().Это перевернуло мое понимание входа в SELinux.

Итак, может кто-нибудь объяснить:

• Как определяется достоверность выбранного пользователем уровня безопасности входа в систему?

• Как именно эта логика реализована в политике, в pam_selinux и в ядре?

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

Answer 1

Учитывая, что я также разделяю проблему «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/политика/src/policy/policy под Red Hat 5) чтобы знать что разрешено или запрещено.

В строгой конфигурации я ясно понимаю, почему все это излишне.И это просто потому, что SELinux является излишество для простых ситуаций.У него есть и другие функции, которые частично оправдывают его, но главная из них — это детальный контроль доступа, который обеспечивает соблюдение разрешений, установленных администратором.Одна из областей, где это используется чаще всего, — это ограничение доступа сервисных демонов только к их необходимому доступу.Настраивать новый демон сложно, но он предотвращает дальнейшее развитие тривиальных эксплойтов, таких как эксплойт общей библиотеки, поскольку рассматриваемому процессу может быть назначена роль, которая не позволит ему запускать команды, не относящиеся к демону, такие как /bin/ls или оболочка.В таких ситуациях эксплойты не принесут вам особой пользы.