В настоящее время SELinux полностью поддерживается в дистрибутивах RedHatEnterpriseLinux 4, FedoraCore 2 и 3, GentooHardenedLinux, в каждом из которых имеется параметр включения SELinux во время установки ОС.
SE Linux обеспечивает большую безопасность вашей системы. Пользователям могут быть назначены предопределённые роли таким образом, что они не смогут получить доступ к файлам и процессам, которыми они не владеют. При этом не существует эквивалента операции "chmod 777". Это отличается от обычной системы Unix-привилегий в том, что определённые пользователем роли, или контексты безопасности в которых они находятся, имеют ограниченный, но более управляемый доступ к файлам и другим ресурсам. Рассмотрим пользовательский файл .rhosts на обычной Unix системе. Если всем дать доступ на запись в этот файл, тогда кто угодно сможет зайти в систему и причинить массу неприятностей. Используя SE Linux, вы можете контролировать возможность пользователя изменять права доступа в своему файлу .rhosts, а кроме того запретить другим людям писать в этот файл даже после того, как владелец это разрешил.
Частый вопрос, это как связаны права доступа SE Linux и стандартные права Unix. Когда вы выполняете какую-либо операцию, в первую очередь проверяются права доступа Unix. Если они разрешают выполнить операцию, тогда проверяются права SE Linux. Только тогда операция будет разрешена или запрещена. Но если права доступа Unix запрещают операцию, то проверка прав SE Linux не производится, а операция запрещается.
Рассмотрим другой пример. Допустим, есть ошибка в программе /usr/bin/passwd, которая позволяет выполнить команду chmod 666 /etc/shadow. В этом случае вступают в действия права SE Linux, которые предотвратят неавторизированный доступ к файлу.
2.1.2 Используемая терминология
Cущность (identity)
Сущность в SE Linux это не то же, что и традиционный идентификатор пользователя (Unix uid, user id). Они могут сосуществовать в одной системе, но их смысл совершенно разный. Сущность в SE Linux формирует часть контекста безопасности, который задает домены, в которые можно войти. Т.е. что собственно можно сделать. Сущность SE Linux может иметь одинаковое с именем пользователя символьное представление (чаще всего так и есть), но важно понимать, что это две разные вещи. Выполнение команды su не меняет сущности пользователя в SE Linux.
Пример:
Непривилегированный пользователь test выполняет команду id (в SE Linux) и видит свой контекст безопасности:
context=test:user_r:user_t
Часть контекста "test" представляет сущность. Теперь, пользователь test выполняет su, чтобы получить привилегии пользователя root, и вызывает id, и видит, что контекст всё ещё:
context=test:user_r:user_t
то есть, контекст остался прежним и не изменился на контекст пользователя root. Однако, если сущность test разрешает доступ к роли sysadm_r, и пользователь это сделает (введя команду newrole -r, детальнее команда рассматривается ниже), и снова выполнит id, то увидит уже:
context=test:sysadm_r:sysadm_t
Итак, сущность осталась той же, но роль и домен (второе и третье поле соответственно) изменились. Такой стиль работы с сущностью обеспечивает возможность идентификации пользователя. Ключевым моментом в безопасности системы является то, что сущность пользователя определяет какие роли и домены могут быть использованы.
Субъекты, объекты и политики.
Тремя важнейшими концепциями структуры безопасности SELinux являются субъекты (subject), объекты (object) и действия (action). С точки зрения SELinux всю работу системы можно описать как выполнение субъектами действий над объектами. Субъектами считаются процессы, действующие как от имени определенных пользователей, так и самостоятельно (серверные процессы). Объектами являются, прежде всего, объекты файловой системы (файлы, каталоги, ссылки), процессы (когда один процесс-субъект выполняет операции с другим процессом, второй процесс выступает в роли объекта), а также дескрипторы файлов (в том числе сокеты, что повышает безопасность работы с сетью) и объекты межпроцессного взаимодействия, не связанные с дескрипторами файлов. Действия в SELinux — это любые операции, которые субъект может выполнить над объектом. Собственно говоря, основная часть работы системы безопасности как раз и заключается в принятии решения о том, имеет ли право данный субъект выполнить данное действие над данным объектом.
Решение о допустимости или не допустимости действия принимается системой на основе политик, представляющих собой способ описания поведения системы безопасности, абстрагирующийся от таких низкоуровневых понятий как векторы доступа (аналоги масок доступа в обычной Linux-системе). Формирование политик безопасности в SELinux напоминает программирование: политика описывается на специальном языке, затем файл политики компилируется в двоичный модуль (обычно при этом используется хорошо знакомая программистам утилита make), а скомпилированный файл динамически загружается в ядро операционной системы.
ПолитикиSELinux позволяют определить, какое решение следует принять для отдельных операций и классов операций: allow (разрешить операцию); auditallow (занести операцию в журнал, независимо от того, разрешена она или нет); dontaudit (запретить операцию, но не вносить данные о попытке выполнить операцию в журнал). Описать логику совместной работы подобных установок можно так: если операция разрешена, она заносится в журнал только в том случае, если принято решение auditallow. Если операция не разрешена, она не заносится в журнал только в том случае, если принято решение dontaudit. Таким образом, в SELinux политика разрешения операций тесно связана с их журналированием.
Домен (domain).
Каждый процесс выполняется в домене. Домен однозначно определяет привилегии процесса. По существу домен это список того, что может делать процесс, или какие действия процесс может выполнять над различными типами. Представляйте себе домен, как стандартный Unix uid. Пускай у пользователя root есть какая-то программа, для которой он выполнил команду chmod 4777 (установил атрибут setuid). Кто угодно в системе, даже пользователь nobody, может выполнить эту программу с полномочиями пользователя root, тем самым, нарушая безопасность системы. При использовании SE Linux, процесс, инициирующий переход в привилегированный домен, должен иметь роль, которой разрешено использовать этот домен, иначе процесс работать не сможет.
В качестве примеров доменов можно привести sysadm_t, домен системной администрации, и user_t, который является общим доменом для непривилегированных пользователей. Процесс init выполняется в домене init_t, а named -- в домене named_t.
Тип (type).
Тип задаётся для объекта и определяет доступ к этому объекту. Т.е. это приблизительно то же самое, что и домен, но домен относится к процессам, а тип к таким объектам, как каталоги, файлы, сокеты и т.п.
Типы объединяют группы субъектов и объектов, предоставляя им определенные права. Важной функцией типов является ограничение возможных действий субъекта над объектом. По этой причине типы иногда называют «песочницами SELinux» (SELinuxsandbox).
В классических работах по безопасности систем (в частности, в модели Flask) понятия «тип» и «домен» имеют разные значения, однако в SELinux эти понятия почти синонимы. Мы говорим о типах, когда речь идет об объектах и о доменах, когда речь идет о субъектах. Домены можно описать как множества процессов (субъектов), обладающих одинаковыми правами. Например, Web-сервер Apache принадлежит домену (типу) httpd_t и обладает всеми правами, связанными с этим доменом. К этому же типу относятся файлы, к которым демон httpd должен иметь полный доступ. В SELinux действует механизм принудительного присвоения типов (typeenforcement). В соответствии с этим механизмом каждый процесс оказывается принадлежащим к определенному типу (домену), определяющему права этого процесса. Очевидно, что без принудительного присвоения типов система обязательного контроля доступа не могла бы работать.
Роль (role).
Роль определяет, какие домены могут быть использованы. Домены, к которым имеет доступ пользовательская роль, предопределяются в конфигурационных файлах политики. Если роль не имеет доступа к заданному домену (в базе данных политики), то при попытке выполнить это действие доступ будет запрещён.
Роли представляют собой наборы привилегий. В любой момент времени каждый пользователь может выступать в одной из доступных ему ролей. Роли позволяют предоставлять пользователю дополнительные привилегии, не утрачивая его идентичности, как это происходит при применении команды su в традиционных системах Unix/Linux. Политика безопасности SELinux может налагать ограничения не только на количество ролей, доступных процессу, но и определять правила перехода из одной роли в другую. Не всякий переход из одной роли в другую допустим.
Очевидно, что роли гораздо чаще используются субъектами, чем объектами, а некоторые объекты (скажем, дисковые файлы), вообще не нуждаются в ролях. Таким объектам присваиваются «пустые роли», не влияющие на безопасность.
Пример:
для того, чтобы разрешить пользователю из домена user_t (домен непривилегированных пользователей) выполнять команду passwd, в соответствующем файле конфигурации указано:
role user_r types user_passwd_t
Она означает, что пользователь с ролью user_r может входить в домен user_passwd_t, т.е. может выполнять команду passwd.
Контексты безопасности.
Права субъектов и объектов определяются в SELinux контекстами безопасности, состоящими из идентификатора, роли и типа объекта. Идентификатор субъекта — это идентификатор пользователя SELinux, создавшего процесс-субъект. Идентификатором объекта является идентификатор пользователя-владельца объекта (обычно это пользователь, создавший объект).