SELinux 1

SELinux

В SELinux субъекты выполняют определенные операции над объектами, и политика безопасности определяет, какие из этих операций разрешены или запрещены. Субъектами обычно являются процессы или потоки. Объектами обычно являются файлы, директории, порты TCP/IP, сетевые интерфейсы.

  1. контекст процесса, который на что-то воздействует, называется доменом.
  2. контекст ресурса, на котором действует процесс, называется типом.
  3. класс объекта ресурса (например, файла или сокета) называется классом
  4. разрешение или разрешения, которые разрешены с учетом домена, типа и класса, являются разрешениями.

Учитывая это, оператор разрешения SELinux структурирован следующим образом:

   allow domain(1) type(2):class(3) { permissions(4) }; 

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

Давайте посмотрим на контекст процессов в системе помеченной метками безопасности SELinux, эти метки хранятся в расширенных атрибутах файловой системы. После установки политики система автоматически будет помечена метками безопасности(заранее подготовленными скриптами). Примечание! Не рекомендуется отключать SELinux(при необходимости) лучше перевести его в разрешительный режим (permissive) это можно сделать в файле конфигурации /etc/selinux/config или с помощью утилиты setenforce. Почему так сделать лучше? Дело в том, что система имеет метки безопасности и помечает новые файлы метками безопасности согласно политике или при копировании(перемещении) файла, при отключенном SELinux(disabled) у вас появятся файлы в системе без меток безопасности, после включения SELinux вам необходимо будет заново восстановить метки утилитой restorecon или будет неопределенное поведение системы.

root@selinux ~  ps -eZ | grep -E '(systemd)' 
system_u:system_r:init_t:s0-s15:c0.c1023 1 ?     00:00:01 systemd 
......................

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

system_u - пользователь 
system_r - роль
init_t - тип
s0-s15 - диапазон чувствительности имеет иерархическую структуру, это говорит о том, что в данной системе включен режим MLS Многоуровневой безопасности, можно немного рассказать и о нем. Режим MLS основан на моделе чтение вниз, запись вверх, пишем читаем на одном уровне. Тем самым получаем конфиденциальность данных. То есть процесс с уровнем s4 может читать на уровнях s0,s1,s2,s3 но записывать на них не может, записывать может на уровне s4(и читать)-s15. Но это все остается на усмотрение автора политики, также как и количество уровней чувствительности, это переменная времени компиляции.
c0:c1023 - дипазон категорий, категории не иерархические. Давайте разберем как работают категории. Процесс с уровнем s0-s2:c0:c333 и процесс s0-s2:c555, хотя и работают на одинаковых уровнях чувствительности, доступа на запись не имеют так как нету пересечении категорий. 

Утилита auditallow удобный и быстрый инструмент для работы с отказами avc(сервер безопасности, принимающий решения о переходе или отказе в доступе. Немного остановимся на нем, он кэширует данные для того, что бы система работала быстрее, падение производительности совсем минимальное с включенным SELinux доли процента, по разнчм данным. На вычисление решения об отказе или переходе влиют несколько факторов, версия политики, версия ядра, то есть на разных системах решения могут отличаться).

 root kernel: audit: type=1400 audit(1708133433.480:897): avc:  denied  { write } for  pid=1051 comm="Cinammon" 
 path="/dev/input/event7" dev="devtmpfs" ino=872 scontext=user_u:user_r:user_t:s0 tcontext=system_u:object_r:event_device_t:s0 
 tclass=chr_file permissive=1

Давайте разберем этот отказ:

 audit(170....) = время в секундах с 1970 года. 
 avc: denied { write } = отказано в записи
 pid=1051 = pid процесса
 comm = команда здесь мы видим Cinammon
 path и dev = путь и устройство 
 ino = инода
 scontext и tcontext = исходный контекст и целевой контекст соответсвенно.
 tclass - символ(файл) 
 permissive = говорит о том что SELinux работает в разрешительном режиме, но регистрирует все отказы, что очень удобно при отладке 
политики.

Давайте посмотрим на правило auditallow:

module.te require {

      user_t;
      event_device_t;
      class chr_file write;

}

allow user_t event_device_t:chr_file write;

Мы можем скомпилировать модуль политики и добавить разрешающее правило для всех user_t разрешить переход event_device_t. Есть ли у нас еще какие-то варианты? Давайте попробуем посмотреть на метку безопасности:

root ~ ls -lZ /usr/bin/Cinammon 
system_u:system_r:bin_t

Можно скорректировать контекст Cinammon утилитой semanage, давайте попробуем это сделать.

root ~ semanage fcontext -a -t xsession_exec_t "/usr/bin/Cinammon"
root ~ restorecon -Rv /usr/bin 

Воспользуемся утилитой getsebool (SELinux позволяет менять булевые логические значения безопасносности)

root ~ getsebool -a

abrt_anon_write --> off
abrt_handle_event -> off
apport_console_login -> on
apport_cvs_read_shadow -> off
...
xserver_allow_dri -> off (вероятно то что нужно)

давайте поменяем разрешение на доступ c помощью утилиты setsebool

root ~ setsebool xserver_allow_dri on (-P опция позволит сохранить изменения после перезагрузки, иначе изменения вернуться в 
исходное состояние при перезагрузке)

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