Linux dac что это

Пользователь — авторизованное лицо, обладающее учетной записью. Пользователи могут использовать систему одним из следующих способов:

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

Пользователь должен выполнить вход в локальной системе, чтобы получить доступ к защищенным ресурсам системы. После аутентификации пользователь может получить доступ к файлам или выполнить программы на локальном компьютере, либо выполнить сетевые запросы к другим компьютерам в системе. Единственные субъекты в системе — процессы. Процесс состоит из адресного пространства и контекста исполнения. Процесс ограничен компьютером; не существует никакого механизма, позволяющего диспетчеризировать процесс, чтобы запустить его удаленно (по TCP/IP) на другом узле. У каждого процесса есть идентификатор процесса (PID), который уникален на локальном компьютере, где выполняется процесс, однако идентификатора процессов не уникальны в пределах всех систем. Например, у каждого узла в системе есть процесс init , идентификатор которого PID=1. Далее в этой статье объясняется, как родительский процесс создает дочерний процесс, создавая его клон с помощью системного вызова clone , fork или vfork ; дочерний элемент тогда может использовать системный вызов execve, чтобы загрузить новую программу.

Объекты — пассивные хранилища данных. В исследуемой системе определены три типа объектов: именованные объекты, которые являются ресурсами, например файлы и объекты IPC, которыми могут управлять многочисленные пользователи, использующие соглашение о присвоении имен, определенное в интерфейсе TSF;

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

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

Система Linux реализует политику дискретного контроля доступа (DAC) для всех именованных объектов и политику повторного использования объектов для всех объектов-хранилищ. Реализация политики DAC означает ее различное применение к различным классам объектов, во всех случаях в основе этой политики лежат идентификационная информация пользователя (пользовательский идентификатор) и членство пользователя в группах, связанное с иднтифиатором пользователя.

В дополнение к политике DAC, Linux также осуществляет политику MAC для всех именованных объектов. Политика DAC осуществляется первой, а политика MAC применяется, только если DAC не запрещает разрешенные ею операции. Политика MAC не авторитетная, т.е. отказ в доступе, определенный политикой DAC, не может быть переопределен политикой MAC. Реализация политики MAC, означает ее различное применение к различным классам объектов; во всех случаях в основе этой политики лежат данные о домене пользователя и типе объекта.

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

Исследуемая система использует как аппаратный, так и программный механизмы защиты данных.

К аппаратным механизмам, используемым Linux, чтобы обеспечить защищенный домен для работы самой операционной системы, относятся процессор со многими состояниями, защиту сегментов памяти и защиту страниц виртуальной памяти. Программное обеспечение TOE полагается на эти аппаратные механизмы для реализации изоляции TSF, обеспечения надежной защиты, которую невозможно обойти, и разделение адресных пространств процессов.

Пользователь может войти в систему через консоль в других подключенных напрямую терминалах или при помощи сетевого соединения. Основой для аутентификации является пароль, введенный пользователем, и данные аутентификации, которые хранятся в защищенном файле, или другие типы учетных данных, например, криптографические ключи при использовании SSH.

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

Архитектура системы обеспечивает самозащиту TSF и механизмы изоляции процессов.

Источник

Bog BOS: Механизмы доступа DAC и MAC, SELinux в RHEL

Традиционный дискреционный механизм доступа (DAC, Discretionary Access Control) подразумевает наличие владельца у каждого защищаемого объекта. Данный владелец определяет права доступа пользователей к объекту. Каждый процесс (программа) запускается от имени определённого пользователя и права доступа к объектам определяются на основании идентификации субъектов или групп. Субъекты также могут передавать права другим субъектам. В Unix каждый объект представляется файлом. Для каждого файла задаются 3 группы прав: для владельца, для членов своей группы и для всех прочих. В каждую группу входят права на чтение, запись и исполнение (прохождение для файлов-каталогов). Ещё есть дополнительные флаги sticky и suid. POSIX ACL увеличивает гибкость механизма DAC, но не позволяет выйти за его рамки.

Мандатный механизм доступа (MAC, Mandatory Access Control) позволяет задать явные правила доступа субъектов (программ, действующих от имени пользователя) к объектам (файлы, устройства, сокеты, порты, процессы) в виде политики доступа. Политика задаётся не владельцем объекта и не может быть изменена. Права на передачу прав определяются также в политике.

Одним из вариантов мандатного доступа является модель домен-тип. Процесс запускается в поименованном домене безопасности (т.е. имеет определённый уровень доступа), а каждый объект имеет определённый тип (так сказать, уровень секретности). Не надо считать, что один уровень выше другого — ранжирование в общем случае не определено. Политика задаёт список правил, ограничивающий возможности доступа доменов к типам. При каждом обращении к ядру проверяется имеет ли право представитель данного домена на данную операцию к объекту данного типа.

Вариант мандатного доступа — многоуровневая иерархическая система доступа (MLS, Multilevel security). В этой модели уровни доступа и секретности ранжированы. Нельзя читать объекты более высокого уровня секретности и писать в объекты с более низким уровнем секретности — модель Белла-Ла Падула (Bell-La Padula, BLP).

Возможен вариант модели домен-тип или MLS с классификацией данных по тематике (MCS, Multicategory security).

Контекст безопасности (метка, label) есть набор атрибутов безопасности, связанных с субъектом или объектом. В модели MLS/MCS метка безопасности объекта называется секретностью (classification), метка безопасности субъекта называется допуском (clearances) и содержит одно значение чувствительности (sensitivity) и ноль или более категорий.

В ядре Linux 2.6 был введён механизм интерфейса модулей безопасности (LSM, Linux Security Modules) между ядром и внешним модулем безопасности, который позволяет реализовать дополнительные политики безопасности при обращении приложений к ядру. Внешний модуль вызывается ядром на уровне системных вызовов после проверки прав доступа в соответствии с DAC (identify-based access control, IBAC, по UID).

SELinux реализован как такой модуль безопасности (policy enforcement server), который собирает контексты безопасности субъекта и объекта, обращается к серверу политик для получения решения о разрешении действия и выполняет это решение (при отказе делается запись в журнал аудита SELinux). Сервер политик кеширует часто используемые правила в AVC (access vector cache). При отсутствии решения в кеше он обращается к серверу безопасности, который использует скомпилированный набор политик, загруженный в ядро при инициализации процессом init. Модуль безопасности также занимается записью меток объектов. В ядре 2.6 SELinux (все его части) собирается с ядром статически, не перестав быть модулем LSM. Может работать в режиме предупреждения (permissive, метки файлов продолжают устанавливаться) или реального запрета доступа (enforcing).

Информация о контексте безопасности объектов хранится в расширенных атрибутах (xattrs) в файловой системе (например, ext3), посмотреть их часть можно с помощью ключа «-Z» команды ls. Используется пространство имён «security.» и имя атрибута «security.selinux». Посмотреть расширенные атрибуты можно командой: «getfattr -n security.selinux имя-файла», изменить:

Команда cp по умолчанию создаёт новые файлы с контекстом, определяемым доменом процесса и типом каталога. Если нет специального правила, то контекст просто наследуется от каталога. Контекст можно задать явно ключом «-Z пользователь:роль:тип» или наследовать от исходного файла ключом «-p». Команда mv сохраняет контекст. Архиваторы tar и star могут сохранять и восстанавливать контекст (ключи —xattrs, —acls, —selinux, —no-xattrs, —no-acls, —no-selinux, -H=exustar). Команда mount позволяет задать контекст безопасности для всей файловой системы: «-o context=контекст».

Политика SELinux представляет собой набор правил в текстовом виде, который компилируется при загрузке. Вместе с дистрибутивом устанавливается уже готовые политики для основных сервисов (более 100 тысяч правил). Реализованы модели домен-тип (Type Enforcement, TE), в т.ч. MCS, доступ на основе ролей (role-based access control, RBAC) и MLS.

Основной политикой в Fedora и RHEL (поддерживается только она) является целевая (target) политика (selinux-policy-targeted.noarch), начиная с FC3. Пакет selinux-policy.noarch (selinux-doc.noarch) содержит документацию о политике (/usr/share/doc/selinux-policy-2.4.6/html/index.html). В рамках этой политики описано разрешённое поведение более 200 процессов (в RHEL5). Остальные процессы выполняются в домене unconfined_t (вывод: хотите обойти ограничения SELinux — переименуйте программу). Доступ к объектам в контексте unconfined_t не ограничивается политикой.

При этом init при запуске процесса проверяет значение булевых переменных типа dhcpd_disable_trans, чтобы определить необходимость перевода (transition) сервиса dhcpd из домена unconfined_t в его родной домен при запуске. Значение булевых переменных можно посмотреть и изменить утилитами getsebool и setsebool. Выполняемый файл /usr/sbin/dhcpd при этом имеет тип dhcpd_exec_t (пользователь — system_u, роль — object_r), а процесс переходит в домен dhcpd_t. Переход в другой домен управляется политикой и может происходить при логине, с помощью утилиты newrole, при запуске процесса («runcon -t домен команда аргументы» или «runcon контекст команда аргументы»). Перевести работающий процесс в новый домен нельзя. При этом в политике определяется в какие домены может переходить субъект с данной ролью. Посмотреть контекст безопасности процессов можно с помощью ключа «-Z» команды ps (или в /proc). Посмотреть контекст своего процесса можно командой id.

Дополнительно для RHEL5 поставляется политика MLS (за отдельные деньги и с ограниченным количеством пакетов, без X Window), selinux-policy-mls.noarch. Данная политика поддерживает модели RBAC (?) и Bell-La Padula. RHEL5 в режиме MLS сертифицирован на EAL4 Augmented with ALC_FLR.3 (LSPP — Labeled Security Protection Profile/EAL4?). В этом режиме команды su/sudo не повышают привилегии, SELinux нельзя отключить или перевести в разрешительный режим, не работают X Windows и многие другие службы.

С помощью этой же политики реализуется модель MCS. В качестве категории можно использовать текстовую строку, затем распределить пользователей по категориям. Пользователи могут метить файлы категориями, которые для них установлены (установить — chcat, посмотреть — «ls -Z»). Файл может быть помечен несколькими категориями, чтобы получить доступ к файлу, пользователь должен быть отнесён ко всем категориям. Проверка производится после проверок DAC и TE. Политики MCS и MLS требуются очень немногим.

Поставляется также «строгая» (strict) политика — всё, что не разрешено, то запрещено (без поддержки), пакет selinux-policy-strict.noarch.

Контекст безопасности в RHEL4 представляется как набор атрибутов пользователь:роль:тип (при задании целевой политики пользователь и роль не используются). Список пользователей можно посмотреть командой «semanage user -l». Пользователь system_u используется для обозначения серверов. Пользователь root — системный администратор. Пользователь user_u — интерактивные пользователи. Кстати, если сервис запускать напрямую, то он будет в контексте user_u, а если с помощью «service . start», то в контексте system_u. Разница может быть заметна. Пользователь root по умолчанию имеет доступ ко всем категориям. Роль (seinfo —roles) object_r используется для обозначения таких системных объектов, как файлы и устройства. Роль system_r используется для большинства процессов в целевой политике. Определено множество доменов (типов субъектов) и типов (seinfo —types) в зависимости от используемых серверов.

От предыдущих реализаций остались понятия security identifiers (SID, «seinfo —initialsid»), которые используются в процессе init до загрузки политики:

сразу после загрузки ядра запускается процесс init с initial SID
монтирует /proc
init проверяет наличие selinuxfs в ядре, отсутствие ключа загрузки selinux=0 или параметра SELINUX=disabled в /etc/selinux/config
монтирует /selinux
режим применения политики определяется ключом загрузки enforcing= или параметром SELINUX в /etc/selinux/config
init запрашивает версию политики в /selinux/policyvers
считывает название политики из /etc/selinux/config (SELINUXTYPE)
загружает политику из /etc/selinux/имя-политики/policy/policy.номер-версии
использует /etc/selinux/targeted/booleans для модификации булевых переменных
модифицированная политика загружается в ядро
initial SID отбражается в нормальный контекст безопасности (для целевой политики — в user_u:system_r:unconfined_t)
init перезапускает себя, чтобы перейти в домен, определённый в политике (в описании сказано, что для целевой политики остаётся в unconfined_t, но в FC6 и CentOS5 он переходит в init_t по правилу «domain_auto_trans(kernel_t, init_exec_t, init_t», т.е. при запуске программы с контекстом файла init_exec_t в домене kernel_t перевести процесс в домен init_t)

SID также используется для dbus-daemon (system_dbusd_exec_t, system_dbusd_t) и nscd (?).

В RHEL5 в контекст безопасности добавлены текущий уровень доступа (low/current sensitivity) и список категорий, наивысший допустимый уровень доступа (high/clearance) и список категорий для него. Для целевой политики всегда задаётся уровень доступа «s0». Чтобы иметь возможность отличать различных пользователей среди user_u (и распределять их по категориям MCS), вводится понятие SELinux идентификатора (semanage login [-a|-l]). Соответствие между идентификатором категории (от 0 до 1023) задаётся в /etc/selinux/имя-политики/setrans.conf. Посмотреть текущее состояние можно командой «chcat -L». Трансляцией занимается сервис mcstrans (его необходимо перезапускать после редактирования файла).

При описании политики используются классы объектов (seinfo —classes) с предустановленным набором возможных действий над объектом:

filesystem (mount, unmount, get attributes, set quotas, relabel)
file (read, write, get and set attributes, lock, relabel, link, rename, append)
dir
tcp_socket
netif (сетевой интерфейс — tcp_recv, tcp_send, udp_send, udp_recv, rawip_recv, rawip_send)
node (узел сети)

Для смены типа политики (и т.п. действий) необходимо:

установить с помощью yum соответстующий пакет (selinux-policy-targeted.noarch, selinux-policy-mls.noarch, selinux-policy-mls.noarch, selinux-policy-strict.noarch
отредактировать /etc/sysconfig/selinux (policy=targeted, mls, strict)
обновить контексты SELinux в файловой системе:

Расположение данных

/etc/sysconfig/selinux (/etc/selinux/config) — переменные, управляющие настройками SELinux при загрузке:
- SELINUX=
- SELINUXTYPE=
- SETLOCALDEFS=0|1 (1 — местные определения пользователей и переменных управляются /etc/selinux/имя-политики/load_policy; 0 — через semanage)
/selinux — псевдофайловая система для получения информации и управления подсистемой SELinux (монтируется процессом init)
- access
- avc
- booleans/ (набор флагов позволяет управлять поведением SELinux; например, отключить применение политики для конкретного сервиса)
- checkreqprot (RHEL5)
- commit_pending_bools
- compat_net (RHEL5)
- context
- create
- disable
- enforce — получение информации о текущем режиме
- load
- member (RHEL5)
- mls
- null
- policyvers
- relabel
- user
RHEL5: /etc/selinux/restorecond.conf (?; список шаблонов имён файлов)
RHEL5: /etc/selinux/semanage.conf (?)
RHEL5: /etc/selinux/setrans.conf (?)
/etc/selinux/имя-политики/policy/ (откомпилированные политики; в RHEL4 содержит один файл policy.номер-версии)
RHEL4: /etc/selinux/имя-политики/booleans
RHEL4: /etc/selinux/имя-политики/policy/src/policy/ (исходные тексты политик, пакет selinux-policy-targeted-sources.noarch)
RHEL5: /usr/share/selinux/имя-политики/ (откомпилированные модули политики)
RHEL5: /usr/share/selinux/devel (исходные тексты политик, пакет selinux-policy-devel)
RHEL5: /etc/selinux/имя-политики/modules/ (?)
/etc/selinux/targeted/modules/active/booleans.local (здесь хранятся результаты «setsebool -P»)
/etc/selinux/имя-политики/contexts/files/ (отсюда restorecon берёт информацию о «правильном» контексте файла для восстановления)
/etc/selinux/имя-политики/contexts/users/ (определяет домен при логине)
RHEL5: /etc/selinux/имя-политики/setrans.conf (соответствие между идентификаторами категорий и текстовым описанием)
RHEL5: /etc/selinux/имя-политики/seusers (?)
/var/log/audit/ (каталог журналов аудита SELinux)

Утилиты (пакеты policycoreutils, setools (дополнительная документация в /usr/share/setools/), libselinux):

sestatus [-v] [-b] (/etc/sestatus.conf задаёт файлы и процессы, контекст которых необходимо показать; -b — показать значения булевых переменных)
selinuxenabled (код возврата 0, если SELinux включён)
seinfo (получение статистики о текущей политике)
- -x (дополнительная информация)
- —types[=имя] (вывести определённые в политике типы объектов)
- —attribs[=имя] (вывести определённые в политике атрибуты типов объектов)
- —classes[=имя] (вывести список классов объектов)
- —roles[=имя] (вывести определённые в политике роли)
- —users[=имя] (вывести список имён пользователей SELinux)
- —boolean[=имя] (вывести список булевых переменных)
- —sensitivities[=имя] (вывести список уровней допуска)
- —categories[=имя] (вывести список категорий)
- —initialsid[=имя] (вывести список «изначальных» SID)
- —fs_use
- —genfscon
- —netifcon (пусто)
- —nodecon
- -p (portcon)
getenforce (текущий статус — Enforcing, permissive, disabled)
setenforce Enforcing | Permissive (выключить не получится, надо перезагружаться с параметром selinux=0)
getsebool <имя-переменной | -a>(вывести текущее значение переменной)
setsebool [-P] имя-переменной=значение (установить значение, -P — постоянно)
togglesebool имя-переменной (обратить значение беловой переменной)
restorecon (восстановить контекст безопасности по умолчанию для указанных файлов; по символьным ссылкам не ходит)
- -i (игнорировать несуществующие файлы)
- -f имя-файла (читать список имён файлов из файла, «-» в качестве stdin)
- -e имя-каталога (пропустить указанный каталог)
- -R | -r (рекурсивно)
- -n (деморежим)
- -o имя-файла (вывести в указанный файл имена файлов с неправильным контекстом)
- -v (показывать осуществлённые изменения типа)
- -vv (показывать осуществлённые изменения типа, роли и пользователя)
- -F (принудительный сброс контекста для приведения в соответствие с file_context, ?)
fixfiles (исправить контекст безопасности указанных файлов или каталогов; по умолчанию правит все файлы на файловых системах ext2, ext3, xfs и jfs, смонтированных без опций контекста безопасности)
- -l имя-файла (журнал работы в указанный файл)
- -o имя-файла (вывести в указанный файл имена файлов с неправильным контекстом)
- -F (принудительный сброс контекста для приведения в соответствие с file_context, ?)
- -R имя-пакета (исправлять контекст безопасности всех файлов данного пакета)
- -C PREVIOUS_FILECONTEXT (?)
- check (вывести текущий и правилтный контекст, но не исправлять)
- restore (изменить неправильные метки)
- [-f] relabel (фигня в документации)
- verify (вывести список файлов с неправильным контекстом, но не исправлять)
setfiles (устанавливает контекст безопасности указанных файлов)
- -c (проверить состояние контекста относительно текущей политики)
- -d (для каждого файла показать какой спецификации он соответствует, ?)
- -l (записывать производимые изменения на syslog)
- -n (деморежим)
semanage -l
audit2why (преобразование журнала аудита в пояснения проблем — неинформативно)
audit2allow (создание правил из записей журнала аудита, не умеет работать с категориями)
- —all (брать записи из аудита и системного журнала)
- —dmesg
- —input имя-файла
- —lastreload (пропускать все записи до последней перезагрузки политики)
- -m, -M, -r, -R (генерация модулей)
- -R (генерирует добавление к политике на основе установленных макро)
setroubleshootd и sealert (пакет setroubleshoot)
chcat
- -L (вывести соответствие между идентификаторами категорий и текстовым описанием)
- -l (приписать пользователя SELinux категориям; приписка вступает в действие при логине)
runcon контекст команда аргументы (запустить процесс в указанном контексте)
newrole -r роль -t тип (запустить новую оболочку со сменой роли и контекста)
semodule (управление модулями политики)
- -l (вывести список установленных модулей, кроме базовых)
secon ?
genhomedircon ?
load_policy ?
open_init_pty ?
restorecond ?
run_init ?
semodule_deps ?
semodule_expand ?
semodule_link ?
semodule_package ?
sepolgen-ifgen ?
avcstat ?
matchpathcon ?
sechecker ?
sediff ?
seinfo ?
sesearch ?

В целевой политике используются следующие роли (seinfo —roles):

system_r (все процессы, кроме пользовательских, имеют эту роль; каждый сервис имеет свой тип)
user_r (все пользовательские процессы имеют эту роль и домен unconfined_t)
object_r (все объекты имеют эту роль; роли имеют смысл только для субъектов)
sysadm_r, staff_r (для совместимости со строгой политикой)

Пользователей SELinux може немного и исключительно для совместимости со строгой политикой (seinfo —users):

system_u (сервисы)
user_u (все пользователи)
root (сервисы, запущенные из командной строки)

Определён всего один уровень доступа — s0.

Определены 1024 абстрактных категории — c0, c1 и т.д. (не используются).

Типы объектов в целевой политике (seinfo —types; ls -Z):

user_home_t
etc_t
etc_runtime_t
etc_aliases_t
auditd_etc_t
shadow_t
adjtime_t
bin_t
sbin_t
имя-сервиса_exec_t
tmp_t
.

Домены в целевой политике (seinfo —types; ps -Z):

init_t
kernel_t
udev_t
restorecond_t
auditd_t
initrc_t
setrans_t (сервис mcstransd)
system_dbusd_t
pcscd_t
apmd_t (apmd, acpid)
inetd_t
sendmail_t
crond_t
xfs_t
hald_t
fsdaemon_t (smartd)
getty_t
xdm_t (xdf, gdm, kdm)
cupsd_t
mono_t
unconfined_t
unconfined_execmem_t
.

Журнал аудита собирается системным модулем kauditd и записывается в syslog или перехватывается службой auditd и записывается в специальный файл /var/log/audit/audit.log. По умолчанию записываются только сообщения об ошибках (при описании политики можно использовать команду dontaudit), но можно включить полный аудит параметром «audit=1» при загрузке. В журнал записываются:

пометка «audit»
тип (AVC, SYSCALL, LOGIN, . )
время в UNIX формате и серийный номер
статус (access, denied)
действие, вызвавшее запрет доступа (например, «read write»)
идентификатор процесса
имя команды
имя файла (относительно корня устройства), inode, устройство
контекст субъекта
контекст объекта
класс объекта

Например, странная проблема с syslogd, отзывающаяся на многих других сервисах. При запуске в /var/log/audit/audit.log получаю сообщение об ошибке:

Файл с inode=3336180 (/etc/services) почему-то имеет тип rpm_script_tmp_t вместо etc_t. Восстанавливаем его («restorecon -v -v /etc/services»), а также файл /etc/hosts и перезапускаем сервис syslog. После этого можно восстановить ранее отключённую целевую политику для сервисов ntpd и apcupsd (и перезапустить их):

Рассмотрим более сложный случай, когда требования в политике установлены, но restorecon не срабатывает. Например, контекст безопасности для /var/clamav требуется целевой политикой как clamd_etc_t, но restorecon ничего об этом не знает:

Можно посмотреть в исходном тексте политик (пакет selinux-policy-devel, файл /usr/share/selinux/devel/include/services/clamav.if) чего от нас хотят и установить контекст вручную:

Однако clamav продолжает хотеть чего-то странного от kernel и meminfo, запускается, но не работает, т.к. нет прав к /var/spool/exim/scan/, так что пока просто выключим:

При запуске bind (CentOS5.1, bind-chroot) в /var/log/audit/audit.log получаю сообщение об ошибке:

Файл с inode=1925770 (/var/named/chroot/var/log/bind/) имеет в описании тип named_conf_t вместо var_log_t. Устанавливаем контекст вручную (без «:s0» для CentOS4):

Модификация политики в RHEL4:

установить пакет selinux-policy-targeted-sources
создать файл local.te (например, с помощью audit2allow) в /etc/selinux/targeted/src/policy/domains/misc
откомпилировать и загрузить
посмотреть, каких прав ещё не хватает и повторить процесс
повторить эти действия при каждом обновлении политики

Проблемы с MySQL и SSL в CentOS 4.5:

Для начала устанавливаем контекст:

Используя audit2allow, выясняем, что в политике не хватает

В RHEL5 (FC6) было введено понятие модульности политики (утилита semodule), что позволяет разбить политику на отдельные модули и устанавливать, обновлять и удалять модули (пакеты) политики независимо друг от друга.

Модификация политики в RHEL5:

установить исходный пакет selinux-policy-XYZ.src.rpm (если надо поменять системные модули)
установить пакет selinux-policy-devel (откомпилированные модули в /usr/share/selinux/targeted/*.pp)
найти в аудите сообщение об ошибке и выделить его в отдельный файл
превратить его с помощью «audit2allow -M имя-своего-модуля -i имя-файла» в локальную политику (исходный текст модуля записывается в /etc/rc.d/init.d/имя-своего-модуля.te, откомпилированного — в /etc/rc.d/init.d/имя-своего-модуля.mod, модуля политики — в /etc/rc.d/init.d/имя-своего-модуля.pp)
на всякий случай, проверить имя-своего-модуля.te
если что-то не так, то исправить текст (имя-своего-модуля.te), откомпилировать его («checkmodule -M -m -o имя-своего-модуля.mod имя-своего-модуля.te») и собрать модуль («semodule_package -o имя-своего-модуля.pp -m имя-своего-модуля.mod»)
загрузить (semodule -i имя-своего-модуля.pp), это изменение переживёт перезагрузку
посмотреть, каких прав ещё не хватает и отредактировать модуль, увеличив номер версии
откомпилировать и пересобрать
обновить модуль в текущей политике (semodule -u имя-своего-модуля)
повторить процесс, пока все ошибки не будут исправлены, например в случае с clamav получилось так:
закрепить успех: setsebool -P clamd_disable_trans=off
при обновлении политики не забыть добавить свой модуль

В тяжёлых случаях можно попробовать утилиту sealert, которая объясняет причины запрета доступа и предлагает готовое решение.

Red Hat Enterprise Linux 5.1: Red Hat Enterprise Linux Deployment Guide (гл. 44, 45 и 46)
Red Hat Enterprise Linux 4: Red Hat SELinux Guide (2005)
SELinux. Максимальный уровень защиты — бесплатно (Маркелов, 2007)
стартовая страница проекта SELinux
разработчик SELinux (Flask) (NSA — National Security Agency USA)
SELinux: теория и практика безопасности (Алексей Федосеев, 18.10.2006)
Administrating SElinux on Red Hat Enterprise Linux (добавление правил, модулей, политик)
A step-by-step guide to building a new SELinux policy module
Fedora SELinux Project Pages
Fedora Core 5 SELinux FAQ
What’s new in SELinux for Red Hat Enterprise Linux 5?
Adding Permissions Using SELinux
SELinux for dummies
policy management/generation tools
Security Enhanced Linux Reference Policy (подробности реализации целевой политики в FC6, локальный файл!)
SELinux By Bill McCarty, O’Reilly, October 2004
SELinux by Example: Using Security Enhanced Linux. Frank Mayer, Karl MacMillan, David Caplan. Prentice Hall. July 27, 2006
Введение в SE Linux: новый SE Linux (2003, Debian)
влияние SELinux скорость ввода-выода (падение на 10%)

Bog BOS: Механизмы доступа DAC и MAC, SELinux в RHEL

Источник

Карта сайта

News

Автора!