Исправление контекста selinux twrp что это

Исправление контекста selinux twrp что это

Сайт недорого!
Контент-маркетинг
Реклама в Интернет
Двойная загрузка Ubuntu и Windows 8
Как сделать двойную загрузку Ubuntu 14.04 и Windows 8 .
Установка программ на Андроид
Установка новых программ на Андроид вполне проста. Есть два способа .
Как раздать Интернет по WiFi на Windows 7
. инструкция как раздать WiFi с Windows 7 .
Точка доступа WiFi на Андроид
. инструкция как раздать WiFi с Андроида .
Точка доступа WiFi на Windows 8.1
. инструкция как раздать WiFi с Windows 8.1 .
USB модем Билайн, Мегафон, МТС
не работает, не подключается — что делать?
Раздача интернета по сети
Как расшарить интернет по сети Linux и Windows.
Точка доступа на Ubuntu 12.04
. Создание WiFi точки доступа на Ubuntu 12.04.
Настроить WiFi на Windows 7
. в этой статье будет описан процесс настройки шаг за шагом с иллюстрациями.
DSL, FTTx — настройка интернета МТС, Ростелеком
Настройка pppoe соединения в Windows 7.
Инструкция по Андроид
. Обзор и описание графического интерфейса Андроид (Android).
Как расшарить файлы и папки Linux
. сетевой доступ без пароля на Linux.
Настройка Ubuntu 14.04
. скорость и удобство работы Ubuntu 14.04 .
Как выбрать SSD?
. характеристики SSD . функции SSD.
Как выбрать монитор?
. характеристики монитора . функции монитора.
Как выбрать планшет?
. характеристики планшета . функции планшета.
Как выбрать фотоаппарат
. будет описано устройство фотоаппарата . перечислены виды фотоаппаратов.
Установка Windows 7 c USB-флешки
Используя USB Flash можно установить Windows 7.
Установка Ubuntu 12.04 LTS .
простая инструкция как установить Linux Ubuntu 12.04 поверх Windows 7 .
Установка Windows XP/7 на нетбук
Сложность установки Windows XP на нетбуки заключается в том, что эти компьютеры не имеют CD-DVD приводов .
Загрузочная установочная USB-флешка Windows 7 или 8
. Как сделать установочную USB-Flash Windows 7 или 8.
Как записывать диски .
. Теория и практика записи CD и DVD дисков .
Как записать MP3 .
Запись диска с mp3 треками, который может быть прочитан в бытовых mp3 плеерах .
Флешка CD-ROM
как создать USB CD-ROM из флеш-диска Apacer .
Записываемые CD и DVD диски .
На сегодняшний день (начало 2005 года) существует три базовых типа (формата) записываемых дисков DVD .
О SELinux написано довольно много, но у большинства этих материалов есть два недостатка. Либо это короткие практические советы как сделать что-то конкретное, но без объяснений того как это устроено и работает. А если статья (или глава в книге) описывает теоретические вопросы, то как-то длинно и запутанно.

Поэтому я и предпринял попытку кратко и доступно описать что такое SELinux. Доступно для тех, кто еще не сталкивался с системами безопасности. В силу стремления к краткости некоторые аспекты я пропустил, для того чтобы не перегружать — в этой статье только самая суть. В частности я не буду тут описывать что из себя представляет "старая" система безопасности Linux — DAC (discretionary access control, избирательное управление доступом). Или в чем отличия между DAC, MAC и RBAC. Желающие, могут об этом почитать например в википедии.

Что такое SELinux?

SELinux (Security Enhanced Linux) это система безопасности основанная на моделях мандатного и ролевого доступа. Была разработана в начале нулевых (2000-х) годов для того, чтобы исправить недостатки традиционной системы безопасности UNIX (DAC). SELinux реализована как компонент ядра Linux начиная с версии ядра 2.6. То есть SELinux можно использовать в любом дистрибутиве Linux с ядром 2.6 или более поздним. Конечно не во всех дистрибутивах использование SELinux облегчено до максимума, но в принципе можно установить почти в любом.

В нескольких дистрибутивах SELinux устанавливается "из коробки" — это RHEL, CentOS, Fedora. Так, что для реального использования нужно только перевести SELinux в режим enforced. Еще в нескольких дистрибутивах SELinux включен в репозитарий, так что его установка дело нескольких минут — например Debian, Ubuntu. В этих дистрибутивах SELinux устанавливается одной командой "sudo apt-get install selinux" с последующей перезагрузкой.

SELinux и DAC

SELinux работает "после" DAC. То есть операции, запрещенные в DAC не могут быть разрешены в SELinux.
Иными словами SELinux дополняет и конкретизирует действия разрешенные через DAC. При этом SELinux работает независимо от DAC.

Субъекты и объекты

Когда говорят о SELinux всегда упоминаются субъекты и объекты. То есть SELinux это разрешения и запреты которые применяются в действиях между субъектами и объектами.

Субъекты — строго говоря это пользователи, которые выполняют какие-либо операции на компьютере. Однако пользователи всегда действуют через те или иные прикладные программы. То есть человек-пользователь не может сам залезть внутрь компьютера и "своими руками" выполнить например запись в файл. Если ему нужно выполнить запись в файл, он запускает какую-либо программу. Поэтому, под субъектами чаще всего подразумеваются именно программы (процессы). Иначе говоря субъекты это те кто выполняет некие действия.

Объекты это то, над чем действия выполняются. Чаще всего под объектами подразумеваются файлы данных. Но это могут быть и устройства и даже программы. Пример:
cat /var/log/syslog | grep SELinux
в этой команде программа grep объект для программы cat. И соответственно программа cat субъект по отношению к программе grep.

Как включить или выключить SELinux

Включение или выключение SELinux выполняется командой selinuxenabled с параметром 1 (включить SELinux) или 0 (выключить SELinux). Если нужно чтобы SELinux был включен/выключен при запуске системы, тогда редактировать файл /etc/selinux/config (параметр SELinux=disable).

Режимы работы SELinux

Permissive — разрешается нарушение политики безопасности. Такие нарушения только регистрируются в системном журнале. То есть по сути SELinux не работает, а только лишь фиксирует нарушения политики безопасности.

Enforced — нарушения политики безопасности блокируются. SELinux работает полностью.

Переключение режимов работы выполняется командой setenforce с параметром 1 (включить enforced) или 0 (включить permissive). Но если нужно чтобы режим работы устанавливался сразу при загрузке системы, тогда редактировать файл /etc/selinux/config (параметр SELinux=) который может принимать одно из трех значений — permissive, enforced, disable (SELinux отключен).

Команда sestatus позволяется узнать текущий режим работы SELinux.

Журналирование SELinux (аудит)

  • настройка auditallow — журналировать события.
  • настройка dontaudit — не журналировать события.
  • если операция allow, то она журналируется лишь в случае auditallow;
  • если операция disallow, то она НЕ журналируется лишь в случае dontaudit.

Контекст безопасности (метка, label) SELinux

Это набор данных состоящий из:

  1. типа пользователя
  2. роли
  3. типа данных или домена процесса
  4. уровней и категорий (используется только в специальных политиках MLS/MCS, в общих политиках эти значения установлены в полный доступ)

Контекст безопасности записывается в атрибуты файла (в файловой системе) и создается при установке SELinux (операция labeling). Уже присвоенный контекст безопасности может быть впоследствии изменен — операция transition.

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

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

Узнать контексты SELinux можно используя стандартные команды с ключом -Z:

  • ps -eZ [| gerp имя_программы] : контекст SELinux для работающих программ (или для конкретной программы).
  • ls -Z : контекст SELinux для файлов.
  • id -Z : контекст SELinux для текущего пользователя.

Пользователь SELinux

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

Перечень разрешенных действий. Возможен переход из одной роли в другую, для изменения полномочий. При этом идентичность пользователя не изменяется (в отличии от команд su/sudo). Роли не совмещаются, они заменяют одна другую.

Читайте также:  После сброса настроек не работает мобильный интернет

Политика безопасности определяет допустимые переходы из одной роли в другую. То есть невозможно перейти из любой роли в любую роль. Поскольку роли всегда связаны с типами (доменами), то часто говорят не о смене ролей, а о смене домена (Domain Transition).

Типы (домены) SELinux

Также известны как SELinux sandbox. Объединяют субъекты и объекты в группы, внутри этих групп определяют разрешенные действия субъектов над объектами. Для субъектов вместо термина тип используется термин домен.
Упрощенно можно сказать так:
тип SELinux — для данных;
домен SELinux — для процессов.
В SELinux, в общих политиках, используется механизм принудительного присвоения типов — Type Enforcement. То есть каждый объект и субъект должен быть обязательно приведен к какому-либо типу (или домену).

Политика SELinux (SELinux Policy)

Совокупность всех описанных в системе соотношений пользователь — роль — тип (домен) — уровень и категория. Все типы пользователей, все роли, все типы/домены. Используется два типа политик:

  • Type Enforcment (TE) — Roles Based Access Control (RBAC). Targeted и strict — наиболее широко используемые TE — RBAC политики SELinux.
  • Bell-La Padula Model Multi-Level Security (MLS) — Multi-Category Security (MCS).

Политика targeted — все процессы не внесенные в специальные ограниченные домены, работают в неограниченном домене unconfined_t. Таким образом осуществляется возможность выполнения процессов которые еще не описаны в политике. Но такие процессы фактически выполняются почти с административными правами. В этом слабое место политики targeted.

Политика strict — все процессы работают в специальных ограниченных доменах, в неограниченном домене unconfined_t никто не работает. Политика strict используется узкоспециально, поскольку требуется ее ручная настройка для каждого конкретного случая. Ведь процессы не описанные в этой политике просто не будут работать. Но зато эта политика обеспечивает полную защиту в рамках тех возможностей которые есть в SELinux.

Политика MLS/MCS

Специальная политика основанная на механизме мандатного доступа. Всем субъектам и объектам присваиваются уровни доступа. В дальнейшем разрешение или запрет на операцию выдается по соотношению уровней доступа у субъекта и объекта. Предмет разрешения только две операции — чтение из файла и запись в файл. Важное отличие этой схемы заключается в том, что разрешения выдаются не на файлы, а на потоки данных связанных с этими файлами.

Правило такое — поток данных не может проходить в направлении понижения уровня доступа. То есть от более высокого уровня к более низкому уровню. Это приводит, на первый взгляд, к нелогичному запрету чтения или доступа в случае если субъект и объект имеют разные уровни доступа. Например субъект с уровнем доступа "секретно" не может писать в файл с уровнем "несекретно". И этот же субъект с правом доступа "секретно" не может читать из файла с уровнем "совершенно секретно", но может писать в этот файл.

Однако, логика тут есть, просто она другая. Если субъект, имеющий уровень "секретно", запишет данные в файл с уровнем "несекретно" то этот файл станет (потенциально) содержать данные уровня "секретно", но при этом будет доступен субъектам уровня "несекретно". То есть станет возможна утечка информации. Поэтому в MLS запись в файлы разрешена только с нижних уровней на верхние.

Эту особенность нужно понимать при присвоении меток уровней доступа.

Помимо уровней, доступ дополнительно регулируется категориями. Субъект не имеющий права доступа к категории "ВМС", не может получить доступ к данным которые имеют метку этой категории. Даже если этот субъект имеет самый высокий уровень доступа.
В контексте SELinux запись об уровнях и категориях выглядит так: "s0-s0:c0.c1023" где "s0-s0" допустимые уровни, а "c0.c1023" допустимые категории. Конкретно такая запись — "s0-s0:c0.c1023" означает высший уровень доступа к любой категории объектов.

Эта часть контекста используется только в специальных политиках MLS/MCS. В общих политиках типа targeted или strict эта часть контекста просто установлена в максимальный уровень разрешений и таким образом не влияет на доступ.

Резюме

Максимальную защиту SELinux дает когда переключен в режим enforced и при этом используется политика strict или политика MLS/MCS.

Если SELinux работает в режиме permissive, то фактически никакой защиты нет — только лишь фиксируются нарушения текущей политики.

Если SELinux переключен в режим enforced, но используется политика targeted, то защита осуществляется только применительно к "известным" программам, для которых в политике определены разрешения и запреты. "Неизвестная" программа фактически имеет административные привилегии.

Если вы живете в г. Краснодар, для вас есть простой способ установить SELinux и научиться им пользоваться. Подробнее.

Иван Сухов, 2012 г.

Если вам оказалась полезна или просто понравилась эта статья, тогда не стесняйтесь — поддержите материально автора. Это легко сделать закинув денежек на Яндекс Кошелек № 410011416229354. Или на телефон +7 918-16-26-331.

Даже небольшая сумма может помочь написанию новых статей 🙂

Или поделитесь ссылкой на эту статью со своими друзьями.

Since installing XtreStoLite 3.1.1, SELinux is set to Enforcing (when I try to boot into TWRP recovery). I tried setting it to permissive (Enforcing = 0) using a terminal emulator (the phone is rooted), but to no effect. It would appear that this is preventing me from booting to TWRP to install Aroma.

(FYI, SELinux Mode Changer didn’t work)

1 Answer 1

If SELinux Mode Changer doesn’t work, and you are properly rooted, then your kernel likely isn’t compiled with permissive mode and was compiled with the flag EXTRA_CFLAGS += -DCONFIG_ALWAYS_ENFORCE=true which doesn’t allow permissive mode to be set in anyway.

You will need to get the kernel source from the manufacturer, which should be available if they are honoring the GPL license, and in the file

Find the line of code that says:

and change the value of it to false and recompile the kernel and make a zImage and flash it to boot.

That being said, TWRP should support SELinux Enforce, just never EVER run a fix permissions

Содержание статьи

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

Система SELinux (Security-Enhanced Linux — Linux с улучшенной безопасностью) была разработана Агентством Национальной Безопасности США и всего за несколько лет стала стандартом в области систем контроля прав доступа. Она была включена в ядро Linux версии 2.6.0 и впервые появилась как полностью работающая из коробки система в дистрибутиве Red Hat Enterprise Linux 4. Впоследствии поддержка SELinux была интегрирована в такие дистрибутивы, как Debian, OpenSUSE и Ubuntu, а дополнительные пакеты, активирующие систему, были добавлены во многие другие более или менее популярные дистрибутивы. Именно благодаря SELinux-дистрибутиву RHEL5, работающему на серверах IBM, удалось получить сертификат безопасности EAL4 Augmented with ALC_FLR.3, который в то время имела лишь одна операционная система — Trusted Solaris. SELinux существенно расширяет ядро Linux, делая операционные системы, построенные на его основе, пригодными к использованию в сферах, где доступ к информации должен быть строго разграничен, а приложения, запускаемые пользователями, должны иметь определенный набор прав, который не выходит за рамки минимально необходимого. Это делает систему привлекательной для госучреждений и военных, однако кажется не совсем понятным, зачем она нужна администраторам рядовых серверов, а уж тем более — обычным пользователям (в Fedora SELinux по умолчанию включен). Сейчас я попытаюсь этот момент пояснить.

Зачем это нужно?

Создатели UNIX наделили свою ОС простым, но весьма гибким и красивым механизмом безопасности. В его основе лежат всем нам известные права доступа на файлы, которые определяют круг лиц (пользователей, процессов), способных выполнять какие-либо действия над файлами и каталогами. Например, мы можем создать исполняемый файл и выставить на него права доступа "-rwxr-xr-x", что будет означать, что мы (то есть владелец файла) можем делать с ним все что захотим, пользователи, входящие в нашу группу, могут его читать и исполнять, а все остальные — только исполнять. Учитывая тот факт, что все устройства в UNIX представлены файлами, такой механизм позволяет не только четко разграничивать доступ пользователей (их приложений) к информации, но и к устройствам и даже к некоторым функциями операционной системы (procfs и sysfs).

Читайте также:  Удалить логотип с циана

Однако, у механизма прав доступа есть два серьезных недостатка. Во-первых, их реализация слишком топорна. Она хорошо подходит для отделения процессов от конфиденциальной информации пользователей, но абсолютно не подходит для гибкого управления их возможностями. Например, чтобы дать какой-либо дисковой утилите (cfdisk, например) возможность модификации хранящейся на диске информации, мы можем либо разрешить полный доступ к диску группе, к которой принадлежит ее владелец, либо запустить ее с правами пользователя root. Как в первом, так и во втором случае мы создадим потенциальную брешь в безопасности: все остальные пользователи/приложения группы получат права доступа к диску, или сама утилита получит наивысшие и безграничные права в системе. А что если нужно дать доступ не к модификации диска, а только к вызову определенных его функций (ioctl)? Здесь права доступа вообще не помогут.

Во-вторых, файлами в Linux представлены далеко не все ресурсы операционной системы. Огромное количество функций ядра скрыто в более чем трех сотнях системных вызовов, большая часть которых доступна для использования абсолютно всем процессам, а если процесс имеет права root, то его возможности вообще никак не ограничиваются. Если, к примеру, мы захотим запустить FTP-сервер на стандартном для него 21 порту, который доступен только процессам с правами root, нам придется всецело довериться его разработчику, поскольку работая от root, FTP-сервер будет способен делать абсолютно все, и ошибка, найденная в его коде, даст взломщику полный контроль над системой. И это из-за простой потребности слушать привилегированный порт!

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

Как это работает?

Если бы ты читал толстую книжку без картинок, то здесь тебя должны были поджидать рассуждения о таких штуках, как дискреционный и мандатный контроль доступа, RBAC, MCS и других околонаучных вещах. К счастью, ты читаешь ][, поэтому тебе придется прослушать более простое объяснение. Понять принцип работы SELinux и заложенные в него идеи проще всего разобравшись с тем, что происходит во время его активации. Что делает SELinux для того, чтобы контролировать обращения процессов к ресурсам ОС? Концептуально можно выделить четыре шага:

    Все субъекты (процессы) и объекты (файлы, системные вызовы и т.д.) взаимодействия помечаются с помощью специальных меток, называемых контекстом безопасности (процессы во время запуска, файлы — во время создания или установки ОС, их метки хранятся в расширенных атрибутах ФС, системные вызовы — при компиляции модуля SELinux).

Когда субъект пытается произвести какое-либо действие в отношении объекта, информация об этом действии поступает к обработчику SELinux.

Обработчик смотрит на контексты безопасности субъекта и объекта и, сверяясь с написанными ранее правилами (так называемая политика), принимает решение о дозволенности действия.

Если действие оказывается правомочным (политика его разрешает), объект (программа) продолжает работать в обычном режиме, в противном случае — она либо принудительно завершается, либо получает вежливый отказ.

В реальной ситуации все это выглядит примерно так: один из скриптов инициализации дистрибутива, имеющий метку initrc_t (на самом деле эту метку имеют порождаемые им процессы, но сейчас это не важно), запускает веб-сервер Apache с помощью файла /usr/sbin/httpd, который имеет метку httpd_exec_t. Как и все остальные действия, запрос на эту операцию поступает в SELinux, в правилах (политике) которого указано, что initrc_t не только имеет право запускать файл с меткой httpd_exec_t, но и то, что при запуске этого файла процесс и его потомки должны получить метку httpd_t. Теперь в системе появляется один или несколько процессов Apache, помеченных как httpd_t. Каждый из них будет подчиняться правилам SELinux, относящимся к этой метке, поэтому, если в политике указано, что httpd_t может получать доступ только к файлам, помеченным как httpd_sys_content_t и 80 порту, Apache не сможет нарушить эти правила (перевесив его на другой порт мы попросту получим ошибку запуска).

Резонный вопрос: откуда берутся правила? Их пишут люди, а точнее — мантейнеры дистрибутивов, что не мешает системному администратору исправить их соответственно своим потребностям. Обычно правила загружаются на первом этапе инициализации ОС, но с помощью особых приемов их можно подсунуть и в уже работающую систему (не перезагружать же сервер с аптаймом 1,5 года только для того, чтобы разрешить FTP-серверу ходить по симлинкам). Типичный объем файла политик SELinux для основных приложений и сервисов дистрибутива может содержать до нескольких сотен тысяч строк, поэтому, чтобы не обременять админов рутинной работой, были созданы инструменты для их автоматической генерации с помощью обучения (например, утилита audit2allow позволяет составлять правила SELinux на основе лог-файлов подсистемы audit).

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

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

Управление доступом на основе ролей или RBAC

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

Когда мы говорили о метках SELinux, я намеренно упустил из виду одну важную деталь. На самом деле контекст безопасности (метка) состоит не из одного, а из трех компонентов (есть еще и четвертый компонент, но об этом пока не стоит задумываться): имени пользователя, роли и типа субъекта (тот самый компонент, который оканчивается на "_t"). Каждый пользователь SELinux (который может быть связан с учетной записью пользователя Linux, но обычно все Linux-пользователи отображаются в SELinux-пользователя unconfined_u) может выполнять несколько ролей, в рамках каждой из которых, ему доступны несколько типов субъектов, а каждый субъект, в свою очередь, может иметь доступ к некоторому количеству объектов.

Как и группы пользователей в классической модели управления доступом UNIX, роли используются для наделения процессов пользователя разными видами полномочий. Однако, фактически они нужны только для того, чтобы тонко регулировать доступ пользователей к данным, то есть при сопровождении компьютерной инфраструктуры больших предприятий, сотрудники которых могут иметь разные уровни доступа к секретной информации (то есть, те самые военные и госучреждения).

При использовании SELinux на обычных серверах, роли не играют большой роли (парадокс, да и только). Любой Linux-дистрибутив, из коробки оснащенный SELinux, по умолчанию использует так называемую "целевую политику", которая предполагает наличие всего нескольких общих SELinux-пользователей и ролей. Например, целевая политика Fedora и RHEL определяет только двух дефолтовых пользователей (на самом деле, есть еще несколько специальных пользователей, но обычно они не используются) и две роли: пользователь system_u, роль system_r и пользователь unconfined_u, роль unconfined_r. Первые используются для запуска системных процессов во время инициализации системы, и в политике четко указано, что запускаемые пользователем system_u (который имеет роль system_r) приложения должны получать конкретный тип субъекта (например, httpd_t), определяемый типом объекта (файла), из которого они запускаются (например, httpd_exec_t). В их отношении действуют строгие правила ограничения, о которых мы говорили в предыдущем разделе. Пользователь unconfined_u и роль unconfined_r предназначены для обычных Linux-пользователей. На последнем этапе инициализации системы запускается менеджер входа в систему (он работает в домене system_u:system_r:login_t), который принимает имя пользователя и его пароль и запускает шелл/графическую оболочку. Однако вместо того, чтобы сохранить текущий контекст безопасности, либо изменить его на system_u:system_r:shell_t в соответствии с правилами политики SELinux (если бы такие были), он обращается к PAM-модулю pam_selinux, который сообщает SELinux, что запущенный менеджером входа процесс (шелл или оболочка) должен получить контекст unconfine d_u:unconfined_r:unconfined_t.

Читайте также:  Госуслуги на компьютер бесплатно windows 7

Смысл этого перехода в том, что целевая политика SELinux имеет правила, которые разрешают приложениям, работающим в этом контексте, делать что угодно, в том числе — запускать другие приложения. Однако, если пользователь запустит приложение, в контексте безопасности которого указан SELinux-пользователь system_u и тип, для которого в политике есть правила, процессы этого приложения будут ограничены в правах точно так же, как если бы они были запущены во время инициализации. Если говорить о контексте безопасности файлов, то здесь роли не используются в принципе, и второе поле всегда равно object_r, а первое будет либо system_u, либо unconfined_u, если это файл, созданный пользователем.

Таким образом, можно сказать, что при использовании целевой политики значимым полем контекста безопасности остается только тип субъекта/объекта, тогда как поля пользователь и роль просто определяют отношение SELinux к процессу (либо он находится под контролем правил, либо нет).

Ограниченные пользователи

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

# useradd -Z xguest_u имя_юзера

Кроме этого можно сделать его дефолтовым, так что ограниченными будут все вновь созданные Linux-юзеры:

# semanage login -m -S targeted -s "xguest_u" -r s0 __default__

Посмотреть список текущих SELinux-юзеров можно так:

# /usr/sbin/semanage login -l

Работаем с системой

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

    SELinux должен быть включен. Глупо отключать SELinux только потому, что так рекомендуют делать многие сисадмины и пользователи. Работу штатных сервисов он нарушить не может, а если тебе нужно расширить возможности какого-либо приложения, это всегда можно сделать с помощью изменения мета-настроек или отключения проверок для определенного типа субъекта (позже я скажу, как это сделать).

"-Z" — твой друг. Да, вся эта возня с контекстами безопасности может вывести из себя. Но есть множество инструментов, которые позволяют выяснить текущий контекст безопасности процессов и файлов:

$ id -Z
$ ps auxZ
$ ls -Z

Найти файлы с нужным контекстом:

$ fi nd /etc -context ‘*net_conf_t’

Восстановить правильный контекст файла:

# restorecon -v /usr/sbin/httpd

И даже узнать, каким должен быть контекст файла и сравнить его с текущим:

  1. Скажи mv – нет! Во время установки дистрибутива все файлы получают определенный контекст безопасности, а все файлы, созданные в процессе работы, — контекст безопасности, определяемый правилами на основе родительского каталога (например, если создать файл внутри каталога /etc, его тип автоматически станет etc_t, а для файлов каталога /var/www/html — httpd_sys_content_t). Однако это работает только в отношении вновь созданных файлов. Во время перемещения файла с помощью mv его контекст сохраняется, что может привести к отказу в доступе (например, Apache не сможет получить доступ к файлу, если его тип не httpd_sys_content_t).

Маны — наше все. В дистрибутивах Fedora и RHEL есть большое количество man-страниц, которые разъясняют все ограничения SELinux в отношении сервисов и демонов. Например, на странице httpd_selinux(8) описано, в каком контексте безопасности работает Apache, какие у него есть полномочия, какие контексты должны иметь доступные ему файлы.

Теперь разберемся с тем, что нужно делать, когда SELinux начинает мешать. Обычно это происходит вследствие того, что админ пытается включить определенную функцию сервиса или как-то перенастроить его, а SELinux начинает сыпать на экран предупреждающие сообщения. Первое, что нужно сделать в этой ситуации, это проверить лог-файлы. Главный журнальный файл SELinux носит имя /var/log/audit/audit.log. Туда поступают "необработанные" сообщения, которые могут быть полезны другим приложениям, но трудны для чтения человеком. Поэтому существует второе место, куда поступают те же сообщения, но в гораздо более понятном формате. Это файл /var/log/messages, в нем сообщения могут выглядеть так:

# grep "SELinux is preventing" /var/log/messages
May 7 18:55:56 localhost setroubleshoot: SELinux is preventing httpd (httpd_t) "getattr" to /var/www/html/index.html (home_dir_t). For complete SELinux messages. run sealert -l de7e30d6-5488-466d-a606-92c9f40d316d

Здесь все должно быть понятно: SELinux запретил субъекту httpd_t (веб-сервер Apache) доступ к файлу /var/www/html/index.html на том основании, что последний имеет неправильный тип объекта (home_dir_t присваивается файлам, созданным в домашнем каталоге пользователя). Для получения более детальной информации SELinux рекомендует выполнить команду sealert -l бла-бла-бла. Эта команда выведет очень информативное сообщение, где будут описаны все обстоятельства произошедшего, причины, по которым они могли возникнуть, а также пути решения проблемы.

В нашем случае причина проста: админ переместил файл index.html из своего домашнего каталога с помощью mv, выставил на него нужного владельца и права, но забыл изменить контекст. Выхода из ситуации два. Либо присвоить файлу правильный контекст с помощью команды chcon:

# chcon -t httpd_sys_content_t /var/www/html/index.html

Либо заставить систему "сбросить" контекст всех файлов каталога:

# restorecon -v /var/www/html

После перезапуска Apache все должно быть ok. Однако этот метод не сработает, если мы захотим переместить корневой каталог Apache в другое место (например, в /www). Дело в том, что chcon изменяет контекст только до следующей переиндексации, с помощью restorecon, которая сбросит контекст файлов каталога /www до default_t (по правилам политики все каталоги, не имеющие родительского каталога, и их файлы получают такой тип). Поэтому мы должны изменить саму политику:

# semanage fcontext -a -t httpd_sys_content_t /www

Первая команда изменит политику так, чтобы дефлтовым типом для каталога /www и его содержимого был httpd_sys_content_t, а вторая сбросит контекст его файлов, так что они получат тот же тип (правила SELinux допускают, чтобы дефолтовые метки каталогов и их содержимого отличались, но для удобства semanage делает их одинаковыми).

Также semanage может быть использована для просмотра списка мета-правил:

# semanage boolean -l

С помощью мета-правил можно контролировать такие аспекты работы приложений, как, например, возможность веб-сервера подключаться к удаленной базе данных (httpd_can_network_connect_db) или разрешение ftp-сервера читать файлы домашнего каталога пользователей (ftp_home_dir) и т.д. Такие правила группируют в себе большое количество низкоуровневых правил, что существенно упрощает жизнь сисадмина.

Чтобы включить/отключить то или иное правило, можно использовать команду setsebool:

# setsebool httpd_can_network_connect_db on

Указав флаг "-P", можно сделать эти правила постоянными между перезагрузками. В самом крайнем случае semanage можно использовать для полного отключения проверок SELinux в отношении определенного субъекта:

# semanage permissive -a httpd_t

Включение производится с помощью похожей команды:

# semanage permissive -d httpd_t

Выводы

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

Warning

По умолчанию tar не сохраняет контексты безопасности файлов, что может привести к проблемам при последующей распаковке. Флаг "—selinux" исправляет это.

Евгений Зобнин

Редактор рубрики X-Mobile. По совместительству сисадмин. Большой фанат Linux, Plan 9, гаджетов и древних видеоигр.

Ссылка на основную публикацию
Зарядка аккумулятора после долива дистиллированной воды
Приведем наиболее часто встречающиеся нарушения правил эксплуатации (1) Заряд током чрезмерно большой силы, превышающим нормальный в несколько раз. Перегрев электролита,...
Драйвер для модема мтс 872ft
Драйверы на модемы USB собраны с официальных сайтов компаний-производителей и других проверенных источников. Официальное ПО от разработчиков поможет исправить ошибки...
Зарядка аккумулятора после долива дистиллированной воды
Приведем наиболее часто встречающиеся нарушения правил эксплуатации (1) Заряд током чрезмерно большой силы, превышающим нормальный в несколько раз. Перегрев электролита,...
Здесь необходимо указать имя mathcad
Это приложение является алфавитным списком диагностических сообщений об ошибках в математических выражениях. Они появляются при попытке ввода, обработки или вычисления...
Adblock detector