Введение в SELinux на CentOS 7 - Часть 2. Файлы и процессы

В first части нашей серии SELinux мы увидели, как включить и отключить SELinux и как изменить некоторые параметры политики, используя логические значения. Во второй части мы поговорим о контексте безопасности файлов и процессов.

Чтобы освежить вашу память из предыдущего урока, контекст безопасности файла - это type, а контекст безопасности процесса - domain.

_ * Примечание * + Команды, пакеты и файлы, показанные в этом руководстве, были протестированы на CentOS 7. Концепции остаются такими же для других распределений. _

В этом руководстве мы будем запускать команды от имени пользователя root, если не указано иное. Если у вас нет доступа к корневой учетной записи и вы используете другую учетную запись с привилегиями sudo, вам необходимо добавить команды перед ключевым словом + sudo +.

Во-первых, давайте создадим четыре учетные записи пользователей, чтобы продемонстрировать возможности SELinux в процессе работы.

В настоящее время вы должны быть пользователем * root *. Давайте добавим следующую команду, чтобы добавить учетную запись * normaluser *:

Затем мы запускаем команду + passwd +, чтобы изменить ее пароль:

Вывод попросит у нас новый пароль. После этого аккаунт будет готов для входа в систему:

Давайте создадим и другие аккаунты:

Цель SELinux - защитить процессы доступа к файлам в среде Linux. Без SELinux процесс или приложение, такое как демон Apache, будет запускаться в контексте пользователя, который его запустил. Таким образом, если ваша система скомпрометирована мошенническим приложением, работающим под пользователем root, приложение может делать все, что захочет, поскольку root имеет всеохватывающие права на каждый файл.

SELinux пытается пойти еще дальше и устранить этот риск. С SELinux процесс или приложение будут иметь только те права, которые ему необходимы, и НИЧЕГО больше. Политика SELinux для приложения будет определять, к каким типам файлов требуется доступ, и к каким процессам она может трансформировать. Политики SELinux написаны разработчиками приложений и поставляются вместе с дистрибутивом Linux, который его поддерживает. Политика - это набор правил, которые отображают процессы и пользователей в соответствии с их правами.

Мы начнем обсуждение этой части руководства с понимания того, что означают SELinux contexts и domains.

Первая часть безопасности ставит label для каждого объекта в системе Linux. Метка похожа на любой другой атрибут файла или процесса (владелец, группа, дата создания и т. Д.); он показывает context ресурса. Так в чем же контекст? Проще говоря, контекст - это набор информации, связанной с безопасностью, которая помогает SELinux принимать решения по управлению доступом. Все в системе Linux может иметь контекст безопасности: учетная запись пользователя, файл, каталог, демон или порт могут иметь свои контексты безопасности. Однако контекст безопасности будет означать разные вещи для разных типов объектов. + ​

Прежде чем идти дальше, обратите внимание на соглашение об именах SELinux. SELinux Для пользователей добавляется суффикс «_u», для ролей - «_r», а для типов (для файлов) или доменов (для процессов) - «_t».

До сих пор мы видели, что файлы и процессы могут иметь разные контексты, и что они ограничены их собственными типами или доменами. Так как же работает процесс? Для запуска процесс должен получить доступ к своим файлам и выполнить с ними некоторые действия (открыть, прочитать, изменить или выполнить). Мы также узнали, что каждый процесс может иметь доступ только к определенным типам ресурсов (файлы, каталоги, порты и т. Д.).

SELinux устанавливает эти правила доступа в политике. Правила доступа следуют стандартной структуре allow Statement:

Мы уже говорили о доменах и типах. * Class * определяет, что на самом деле представляет ресурс (файл, каталог, символическая ссылка, устройство, порты, курсор и т. Д.)

Вот что означает этот общий оператор allow:

Чтобы увидеть, как это работает, давайте рассмотрим контексты безопасности демона httpd, работающего в нашей системе CentOS 7:

Домашним каталогом по умолчанию для веб-сервера является + / var / www / html. Давайте создадим файл в этом каталоге и проверим его контекст:

Файловый контекст для нашего веб-контента будет * httpd_sys_content_t *:

Мы можем использовать команду + sesearch + для проверки типа доступа, разрешенного для демона httpd:

Флаги, используемые с командой, довольно понятны: исходный домен * httpd_t *, тот же домен, в котором работает Apache. Нас интересуют целевые ресурсы, которые являются файлами и имеют контекст типа * httpd_sys_content_t *. Ваш вывод должен выглядеть так:

Обратите внимание на первую строку:

Это говорит о том, что демон httpd (веб-сервер Apache) имеет контроль ввода-вывода, чтение, получение атрибутов, блокировку и открытый доступ к файлам типа * httpd_sys_content *. В этом случае ваш файл + index.html имеет такой же тип.

Пройдя еще дальше, давайте сначала изменим веб-страницу (+ / var / www / html / index.html). Отредактируйте файл, чтобы он содержал этот контент:

Затем мы изменим права доступа к папке + / var / www / + и ее содержимому, а затем перезапустим демон httpd:

Затем мы попытаемся получить к нему доступ из браузера:

изображение: https: //assets.digitalocean.com/articles/SELinuxCentOS7/2.jpg [Доступ к веб-странице с правильной настройкой SELiunux]

_ * Примечание * + В зависимости от того, как настроен ваш сервер, вам может потребоваться включить порт 80 в брандмауэре IPTables для пропуска входящего HTTP-трафика извне сервера. Мы не будем вдаваться в подробности включения портов в IPTables здесь. Есть несколько отличных DigitalOcean articles по теме, которую вы можно использовать. _

Все идет нормально. Демон httpd авторизован для доступа к файлу определенного типа, и мы можем видеть его при доступе через браузер. Теперь давайте изменим контекст файла. Для этого мы будем использовать команду + chcon +. Флаг + - type + для команды позволяет нам указать новый тип для целевого ресурса. Здесь мы меняем тип файла на * var_t *.

Мы можем подтвердить изменение типа:

Далее, когда мы пытаемся получить доступ к веб-странице (т.е. демон httpd пытается прочитать файл), вы можете получить ошибку * Forbidden * или страницу CentOS «Testing 123»:

изображение: https: //assets.digitalocean.com/articles/SELinuxCentOS7/3.jpg [Доступ к веб-странице с неправильной настройкой SELinux]

Так что здесь происходит? Очевидно, что в некотором доступе теперь отказано, но чей это доступ? Что касается SELinux, веб-сервер авторизован для доступа только к определенным типам файлов, и var_t не является одним из таких контекстов. Поскольку мы изменили контекст файла index.html на var_t, Apache больше не может его читать, и мы получаем ошибку.

Чтобы все заработало снова, давайте изменим тип файла с помощью команды + restorecon +. Ключ -v показывает изменение меток контекста:

Если мы попытаемся получить доступ к странице сейчас, она снова покажет текст «Это тестовая веб-страница».

Это важная концепция, которую нужно понять: чтобы убедиться, что файлы и каталоги имеют правильный контекст, необходимо убедиться, что SELinux ведет себя так, как должен. Мы увидим практический пример использования в конце этого раздела, но перед этим давайте поговорим еще о нескольких вещах.

SELinux обеспечивает то, что мы можем назвать «наследованием контекста». Это означает, что, если это не указано в политике, процессы и файлы создаются с учетом контекста их родителей.

Таким образом, если у нас есть процесс с именем «proc_a», порождающий другой процесс с именем «proc_b», то этот процесс будет запущен в том же домене, что и «proc_a», если иное не указано политикой SELinux.

Аналогично, если у нас есть каталог с типом «some_context_t», любой файл или каталог, созданный в нем, будет иметь тот же тип контекста, если в политике не указано иное.

Чтобы проиллюстрировать это, давайте проверим контекст каталога + / var / www / +:

Каталог + html + в + / var / www / + имеет контекст типа * httpd_sys_content_t *. Как мы видели ранее, файл + index.html + внутри него имеет тот же контекст (то есть, контекст родителя):

Это наследство не сохраняется, когда файлы копируются в другое место. В операции копирования скопированный файл или каталог принимает контекст типа целевого расположения. В приведенном ниже фрагменте кода мы копируем файл + index.html + (с контекстом типа «httpd_sys_content_t») в каталог + / var / +:

Если мы проверим контекст скопированного файла, мы увидим, что он изменился на * var_t *, контекст его текущего родительского каталога:

Это изменение контекста может быть отменено предложением + - preserver = context + в команде + cp +.

Когда файлы или каталоги перемещаются, оригинальные контексты сохраняются. В следующей команде мы перемещаем + / var / index.html + в каталог + / etc / +:

Когда мы проверяем контекст перемещенного файла, мы видим, что контекст * var_t * был сохранен в каталоге + / etc / +:

Так почему же мы так озабочены контекстами файлов? Почему эта концепция копирования и перемещения важна? Подумайте об этом: возможно, вы решили скопировать все HTML-файлы вашего веб-сервера в отдельный каталог в корневой папке. Вы сделали это для упрощения процесса резервного копирования, а также для усиления безопасности: вы не хотите, чтобы хакер мог легко угадать, где находятся файлы вашего сайта. Вы обновили управление доступом к каталогу, изменили файл веб-конфигурации, указав новое местоположение, перезапустили службу, но она все равно не работает. Возможно, вы сможете посмотреть контексты каталога и его файлов как следующий шаг устранения неполадок. Давайте запустим это в качестве практического примера.

В предыдущем примере кода мы видели две команды для изменения содержимого файла: + chcon + и + restorecon +. Запуск + chcon + является временной мерой. Вы можете использовать его для временного изменения контекста файла или каталога для устранения ошибок отказа в доступе. Однако этот метод является только временным: файловая система переименовывается или запускает команду + restorecon +, чтобы вернуть файл в исходный контекст.

Кроме того, для запуска + chcon + требуется, чтобы вы знали правильный контекст для файла; флаг + - type + определяет контекст для цели. + restorecon + не нужно это указывать. Если вы запустите + restorecon +, к файлу будет применен правильный контекст, и изменения будут сделаны постоянными.

Но если вы не знаете правильный контекст файла, как система узнает, какой контекст применять при запуске + restorecon +?

Для удобства SELinux «запоминает» контекст каждого файла или каталога на сервере. В CentOS 7 контексты файлов, уже существующих в системе, перечислены в файле + / etc / selinux / target / contexts / files / file_contexts +. Это большой файл, в котором перечислены все типы файлов, связанные с каждым приложением, поддерживаемым дистрибутивом Linux. Контексты новых каталогов и файлов записываются в файл + / etc / selinux / target / contexts / files / file_contexts.local +. Поэтому, когда мы запускаем команду + restorecon +, SELinux ищет правильный контекст из одного из этих двух файлов и применяет его к цели.

Фрагмент кода ниже показывает выдержку из одного из файлов:

Чтобы навсегда изменить контекст нашего файла index.html в + / www / html +, мы должны выполнить двухэтапный процесс.

Чтобы убедиться, что мы можем проверить базу данных контекста файла (обратите внимание, что мы используем файл + file_contexts.local +):

Вы должны увидеть обновленные контексты:

Далее мы запустим команду + restorecon +. Это переназначит файл или каталог с тем, что было записано на предыдущем шаге:

Это должно сбросить контекст на трех уровнях: каталог + / www + верхнего уровня, каталог + / www / html под ним и файл` + index.html` под + / www / html +:

Если мы сейчас попытаемся получить доступ к веб-странице, она должна работать.

Существует отличный инструмент под названием + matchpathcon +, который может помочь в устранении проблем, связанных с контекстом. Эта команда рассмотрит текущий контекст ресурса и сравнит его с тем, что указано в базе данных контекста SELinux. Если отличается, он предложит необходимые изменения. Давайте проверим это с файлом + / www / html / index.html +. Мы будем использовать флаг + -V +, который проверяет контекст:

Выходные данные + matchpathcon + должны показывать, что контекст проверен.

Для неправильно помеченного файла в сообщении будет указан контекст:

До сих пор мы видели, как процессы обращаются к ресурсам файловой системы. Теперь посмотрим, как процессы получают доступ к другим процессам.

Domain transition - это метод, при котором процесс меняет свой контекст с одного домена на другой. Чтобы понять это, допустим, у вас есть процесс с именем proc_a, работающий в контексте contexta_t. При переходе домена proc_a может запускать приложение (программу или исполняемый скрипт) с именем app_x, которое может вызвать другой процесс. Этот новый процесс может называться proc_b, и он может выполняться в домене contextb_t. Таким образом, contexta_t transitioning для contextb_t через app_x. Исполняемый файл app_x работает как entrypoint для contextb_t. Поток может быть проиллюстрирован ниже:

изображение: https: //assets.digitalocean.com/articles/SELinuxCentOS7/4.jpg [Переход домена SELinux]

Случай перехода домена довольно распространен в SELinux. Давайте рассмотрим процесс vsftpd, работающий на нашем сервере. Если он не запущен, мы можем запустить команду + service vsftpd start +, чтобы запустить демон.

Далее мы рассмотрим процесс systemd. Это предок всех процессов. Это замена процесса инициализации System V и выполняется в контексте * init_t *. :

Процесс, выполняющийся в домене * init_t *, является недолговечным: он вызывает двоичный исполняемый файл + / usr / sbin / vsftpd +, который имеет контекст типа * ftpd_exec_t *. Когда двоичный исполняемый файл запускается, он становится самим демоном vsftpd и запускается в домене * ftpd_t *.

Мы можем проверить доменные контексты файлов и процессов:

Показывает нам:

Проверка процесса:

Показывает нам:

Итак, процесс, запущенный в домене * init_t *, выполняет двоичный файл с типом * ftpd_exec_t *. Этот файл запускает демон в домене * ftpd_t *.

Этот переход не является чем-то, что приложение или пользователь может контролировать. Это было оговорено в политике SELinux, которая загружается в память при загрузке системы. На не-SELinux сервере пользователь может запустить процесс, переключившись на более мощную учетную запись (при условии, что он или она имеет на это право). В SELinux такой доступ контролируется предварительно написанными политиками. И это еще одна причина, по которой SELinux внедряет обязательный контроль доступа.

Переход домена зависит от трех строгих правил:

Взяв приведенный выше пример демона vsftpd, давайте запустим команду + sesearch + с различными ключами, чтобы проверить, соответствует ли демон этим трем правилам.

Во-первых, исходный домен init_t должен иметь разрешение на выполнение приложения точки входа с контекстом ftpd_exec_t. Так что, если мы запустим следующую команду:

Результат показывает, что процессы в домене init_t могут читать, получать атрибуты, выполнять и открывать файлы контекста ftpd_exec_t:

Далее мы проверяем, является ли двоичный файл точкой входа для целевого домена ftpd_t:

И действительно, это так:

И, наконец, исходный домен init_t должен иметь разрешение на переход в целевой домен ftpd_t:

Как мы видим ниже, исходный домен имеет такое разрешение:

Когда мы представили концепцию доменов, мы сравнили ее с гипотетическим пузырем вокруг процесса: тем, что определяет, что процесс может и не может делать. Это то, что ограничивает процесс.

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

Примером неограниченного домена процесса будет undefined_t. Это тот же домен, в который вошли пользователи, запускающие их процессы по умолчанию. Мы поговорим о пользователях и их доступах для обработки доменов в следующих разделах.

Сегодня мы рассмотрели некоторые очень важные концепции SELinux. Управление контекстом файлов и процессов лежит в основе успешной реализации SELinux. Как мы увидим в следующей и final часть этой серии, есть Остался еще один кусочек головоломки: пользователь SELinux.