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» (SELinux sandbox).
В классических работах по безопасности систем (в частности, в модели Flask) понятия «тип» и «домен» имеют разные значения, однако в SELinux эти понятия почти синонимы. Мы говорим о типах, когда речь идет об объектах и о доменах, когда речь идет о субъектах. Домены можно описать как множества процессов (субъектов), обладающих одинаковыми правами. Например, Web-сервер Apache принадлежит домену (типу) httpd_t и обладает всеми правами, связанными с этим доменом. К этому же типу относятся файлы, к которым демон httpd должен иметь полный доступ. В SELinux действует механизм принудительного присвоения типов (type enforcement). В соответствии с этим механизмом каждый процесс оказывается принадлежащим к определенному типу (домену), определяющему права этого процесса. Очевидно, что без принудительного присвоения типов система обязательного контроля доступа не могла бы работать.
Роль (role).
Роль определяет, какие домены могут быть использованы. Домены, к которым имеет доступ пользовательская роль, предопределяются в конфигурационных файлах политики. Если роль не имеет доступа к заданному домену (в базе данных политики), то при попытке выполнить это действие доступ будет запрещён.
Роли представляют собой наборы привилегий. В любой момент времени каждый пользователь может выступать в одной из доступных ему ролей. Роли позволяют предоставлять пользователю дополнительные привилегии, не утрачивая его идентичности, как это происходит при применении команды su в традиционных системах Unix/Linux. Политика безопасности SELinux может налагать ограничения не только на количество ролей, доступных процессу, но и определять правила перехода из одной роли в другую. Не всякий переход из одной роли в другую допустим.
Очевидно, что роли гораздо чаще используются субъектами, чем объектами, а некоторые объекты (скажем, дисковые файлы), вообще не нуждаются в ролях. Таким объектам присваиваются «пустые роли», не влияющие на безопасность.
Пример:
для того, чтобы разрешить пользователю из домена user_t (домен непривилегированных пользователей) выполнять команду passwd, в соответствующем файле конфигурации указано:
role user_r types user_passwd_t
Она означает, что пользователь с ролью user_r может входить в домен user_passwd_t, т.е. может выполнять команду passwd.
Контексты безопасности.
Права субъектов и объектов определяются в SELinux контекстами безопасности, состоящими из идентификатора, роли и типа объекта. Идентификатор субъекта — это идентификатор пользователя SELinux, создавшего процесс-субъект. Идентификатором объекта является идентификатор пользователя-владельца объекта (обычно это пользователь, создавший объект).
Каждый субъект и объект идентифицируется собственным контекстом безопасности, которому соответствует идентификатор безопасности SID, причем система контекстов сильно отличается от традиционной системы учетных записей в ОС Linux поэтому возникает задача их взаимодействия. В соответствии с принципом независимости SELinux поддерживает таблицу контекстов безопасности, независимую от таблицы учетных записей Linux. При этом возможно отображение нескольких учетных записей Linux на одну учетную запись SELinux. Таким образом, изменения в учетных записях Linux не влияют на параметры безопасности SELinux.
Модель безопасности SELinux требует, чтобы каждый файл в системе был связан с определенным контекстом безопасности, поэтому в ходе установки всегда выполняется маркировка (labeling) объектов файловой системы. В соответствии с принципом независимости маркировка файлов не влияет на маски доступа к файлам, а в соответствии с принципом приоритета традиционной системы безопасности запреты, наложенные маской доступа, отменяют разрешения SELinux.
Контекст безопасности это набор всех атрибутов, связанных с объектами типа файлов, каталогов, процессов, TCP сокетов и т.п. Контекст безопасности состоит из сущности, роли и домена или типа. Увидеть свой собственный контекст вы можете, выполнив команду id в SE Linux.
Важно понимать различие между доменом и типом.
У процессов есть домен. Когда вы смотрите контекст безопасности процесса (пример команды приведен в следующем разделе), последнее поле -- это домен, например user_passwd_t (если выполняется программа passwd).
Такие объекты как файлы, каталоги, сокеты и т.п. имеют типы. Например, при выполнении команды ls --context для файла, последнее поле представляет тип, такой как user_home_t для файлов, созданных в домашнем каталоге пользователя с ролью user_r.
Вот здесь и накапливается непонимание, где есть домен, а где тип. Рассмотрим файловую систему /proc. У каждого процесса есть домен, а в файловой системе /proc для каждого процесса есть каталог. Каждый процесс имеет метку, или точнее, контекст безопасности, в применении к файлу. Но в файловой системе /proc, метка содержит тип, а не домен. Не смотря на то, что /proc представляет собой выполняющиеся процессы, содержимое /proc является файлами, а потому имеет тип, а не домен.
Вызов команды ls --context /proc выдаёт следующую информацию для процесса init (процесс с идентификатором 1):
dr-xr-xr-x root root system_u:system_r:init_t 1
Метка, или контекст безопасности, говорит нам о том, что этот файл имеет тип init_t. Но, кроме того, это значит, что процесс init выполняется в домене init_t. Каждый файл и каталог файловой системы /proc, соответствующий некоторому процессу, также следует этому соглашению, т.е. тип, указанный в выводе команды ls --context соответствует, так же, домену в котором выполняется процесс.
Ещё одним важным моментом является то, что команды chsid (изменить идентификатор безопасности) и chcon (изменить контекст) не работают на файловой системе /proc, т.к. она не поддерживает изменение меток.
Контекст безопасности файла, например, может варьироваться в зависимости от домена, который создал файл. По умолчанию, новый файл или каталог наследует тип от родительского каталога, однако вы можете задать иную политику.
Пример:
пользователь sasha создаёт файл test в своем домашнем каталоге. После чего выполняет команду ls --context test и видит:
-rw-r--r-- sasha sasha sasha:object_r:user_home_t test
Теперь sasha создаёт файл в каталоге /tmp с именем tmptest и выполняет команду ls --context /tmp/tmptest. Теперь результат такой :
-rw-r--r-- sasha sasha sasha:object_r:user_tmp_t /tmp/tmptest
В первом примере контекст безопасности включал тип "user_home_t", который является типом по умолчанию для домашнего каталога непривилегированного пользователя с ролью user_r. После выполнения второй команды ls --context, видим, что тип теперь user_tmp_t. Это тип по умолчанию для файлов, созданных процессами домена user_t в каталоге типа tmp_t.
Переход (transition).
Решение о переходе, определяет контекст безопасности, который будет назначен запрошенной операции. Есть два основных типа переходов. Первый тип, это переход домена процесса. Он используется при выполнении процесса определённого типа. Второй, это переход типа файла, который применяется при создании файла в определённых каталогах.
Пример:
Пример перехода второго типа (переход типа файла) приведён в предыдущем разделе "контекст безопасности". При выполнении команды ls --context вы можете видеть тип файла (т.е. user_home_t и user_tmp_t в вышеприведённом примере). Итак, при создании пользователем файла в каталоге /tmp происходит переход в тип user_tmp_t и новый файл помечается соответствующим образом.
Рассмотрим теперь пример перехода домена процесса. Запустите ssh из-под обычного пользователя, или, точнее, из домена user_t (помните, что для проверки текущего контекста безопасности можно использовать команду id). Теперь выполите ps ax --context и найдите строку с данными о команде ssh. Полагая, что это сделал пользователь sasha, она, в частности, увидит:
sasha:user_r:user_ssh_t
Процесс ssh выполняется в домене user_ssh_t потому что программа имеет тип ssh_exec_t, а роль user_r имеет право доступа в домен user_ssh_t.
Все ниже изложенные операции и команды будут рассмотрены для Fedora Core 4 (выбор именно этого дистрибутива будет пояснен чуть ниже, в соответствующей главе).
SELinux входит в стандартную установку данного дистрибутива, поэтому не пришлось делать перекомпиляцию ядра для включения поддержки данной технологии и установки дополнительных модулей и заплаток на ядро. В Приложении 1 приведен краткий алгоритм установки поддержки SELinux в более старых версиях Fedora Core.
0 комментариев