Confining Samba with SELinux (in Russian)

En: As Dan Walsh wrote he started updating the man pages for different confined domains. So, I will update Russian version because now in Fedora 8, Russian man pages are still based on old version of man pages.

Ru: Страницы руководств по сконфигурированным (для которых существует политика SELinux) доменам не обновлялись с 2005 года. Недавно Dan Walsh начал переписывать ряд руководств, приводя описание к современному состоянию политик. Обновленная страница samba_selinux уже в Fedora 7/8. Перевод же в дистрибутиве пока не доступен (точнее, там мой старый перевод на основе старого же оригинала). Новый:

$ man samba_selinux

samba_selinux(8) Samba Selinux Policy documentation samba_selinux(8)

НАЗВАНИЕ

samba_selinux - Защита Samba при помощи SELinux

ОПИСАНИЕ
Security-Enhanced Linux обеспечивает защиту сервера Samba при помощи гибко настраиваемого мандатного контроля доступа. По умолчанию политика SELinux для Samba использует принцип наименьших привилегий. Для настройки того, как SELinux работает с Samba, существует ряд переключателей (booleans) и контекстов файлов.

ОБЩИЙ ДОСТУП К ФАЙЛАМ
SELinux требует наличия у файлов расширенных атрибутов, определяющих тип файла. Политика управляет видом доступа демона к этим файлам. Когда вы предоставляете общий доступ к файлам, у вас есть несколько вариантов как пометить файлы. Если вы хотите предоставить общий доступ к файлам/директориям за пределами домашних или стандартных директорий, этим файлам/директориям необходимо присвоить контекст samba_share_t. Например, при создании специальной директории /var/eng, необходимо установить контекст для этой директории при помощи утилиты chcon.

# chcon -R -t samba_share_t /var/eng

Однако назначенные таким образом метки не сохранятся при выполнении операции обновления меток. Наилучшее решение - сделать эти изменения постоянными. Для этого требуется рассказать системе SELinux об этих изменениях. Команда semanage может изменить назначенный по умолчанию контекст файлов на вашей машине. А команда restorecon прочтет файл file_context и установит описанные контексты для файлов и директорий..

# semange fcontext -a -t samba_share_t ’/var/eng(/.*)?’
# restorecon -R -v /var/eng

ОБЩИЙ ДОСТУП К ДОМАШНИМ ДИРЕКТОРИЯМ
По умолчанию политика SELinux запрещает удаленный доступ к домашним директориям. Если вы настроили эту машину как сервер Samba и желаете предоставить доступ к домашним директориям, вы должны установить переключатель samba_enable_home_dirs.

# setsebool -P samba_enable_home_dirs 1

СОВМЕСТНОЕ ВЛАДЕНИЕ ФАЙЛАМИ
Если вы хотите организовать между несколькими доменами (Apache, FTP, rsync, Samba) совместный доступ к файлам, то вы можете установить контекст файлов в public_content_t и public_content_rw_t. Данный контекст позволяет любому из выше перечисленных демонов читать содержимое. Если вы хотите, чтобы конкретный домен имел право записи в домен public_content_rw_t, вы должны установить соответствующий переключатель allow_ДОМЕН_anon_write. Таким образом, для samba вы должны выполнить:

# semange fcontext -a -t public_content_rw_t ’/var/eng(/.*)?’
# restorecon -R -v /var/eng
# setsebool -P allow_smbd_anon_write 1

ОБЩИЙ ДОСТУП К СИСТЕМНЫМ ФАЙЛАМ
Замечание: Вы не должны применять действия, описанные выше, к стандартным или домашним директориям! Например, директориям, принадлежащим RPM. Если вы хотите сделать /usr доступным через Samba, то изменение контекста этой директории и всех поддиректорий на samba_share_t - плохая идея. Дело в том, что другие сконфигурированные домены не смогут получить доступ на чтение к /usr, что может вызвать катастрофические последствия для машины. Для предоставления общего доступа к стандартным директориям существуют два переключателя (booleans). Если вы хотите предоставить общий доступ только на чтение к любой стандартной директории, вы можете установить переключатель samba_export_all_ro.

# setsebool -P samba_export_all_ro 1

Данный переключатель позволяет Samba прочесть каждый файл в системе. Аналогично, если вы хотите предоставить общий доступ Samba ко всем файлам и директориям в системе, установите samba_export_all_rw

# setsebool -P samba_export_all_rw 1

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

ОБЩИЙ ДОСТУП К NFS ФАЙЛАМ
По умолчанию политика SELinux запрещает демонам Samba чтение/запись nfs ресурсов. Если вы используете Samba для предоставления общего доступа к файловым системам NFS, то вам нужно включить переключатель samba_share_nfs

# setsebool -P samba_share_nfs 1

ИСПОЛЬЗОВАНИЕ CIFS/SAMBA ДЛЯ РАЗМЕЩЕНИЯ ДОМАШНИХ ДИРЕКТОРИЙ
Политика SELinux для Samba запрещает любому сконфигурированному приложению доступ к удаленным samba-ресурсам, смонтированным на вашей машине. Если вы хотите использовать удаленный сервер Samba для хранения домашних директорий вашей машины, то необходимо установить переключатель use_samba_home_dirs.

# setsebool -P use_samba_home_dirs 1

СКРИПТЫ SAMBA
Samba можно настроить для исполнения пользовательских скриптов. По умолчанию если вы инсталлируете такие скрипты в /var/lib/samba/scripts, то они будут помечены как samba_unconfined_script_exec_t. Так как эти скрипты могут использоваться для различных действий в системе, вы можете запускать их как несконфигурированные. Но при этом вам необходимо включить переключатель samba_run_unconfined

# setsebool -P samba_run_unconfined 1

Если вы пишете собственную политику, в файле samba.if описан интерфейс, называемый samba_helper_template(APP). Этот интерфейс создает файловый контекст samba_APP_script_exec_t, и домен samba_APP_script_t. Samba запускает скрипт, помеченный samba_app_script_exec_t, в домене samba_APP_script_t. Далее при помощи audit2allow вы можете создать политику для своего скрипта.

ИСПОЛЬЗОВАНИЕ SAMBA В КАЧЕСТВЕ КОНТРОЛЛЕРА ДОМЕНА
Если вы хотите использовать samba как контроллер домена, то есть добавить машины в файл passwd на сервере под управлением Linux, вам нужно включить переключатель samba_domain_controller. Это позволит демону Samba запускать и осуществлять переход в домены утилит passwd, useradd и groupadd. Данные утилиты предназначены для манипуляций базой данных passwd.

УТИЛИТА С ГРАФИЧЕСКИМ ИНТЕРФЕЙСОМ system-config-selinux
Для управления всеми описанными выше контекстами файлов и переключателями SELinux можно использовать утилиту с графическим интерфейсом system-config-selinux.

АВТОРЫ
Эту страницу руководства написал Dan Walsh.
Перевод руководства - Андрей Маркелов, 2007г.

СМОТРИ ТАКЖЕ
selinux(8), semanage(8), samba(7), chcon(1), setsebool(8), restorecon(8),

dwalsh at redhat com 9 Ноября 2007 samba_selinux(8)

Hello Planet Fedora!

I've been reading Planet Fedora for a long time, and was very pleased to see the first blog in russian (my native language). Thank you Seth Vidal for adding me as well.
I am RHCE/RHCI in a russian Red Hat Partner company. Most of the articles in my blog are about Fedora/RHEL/SELinux. In Fedora project I work in mosttly as a translator.

Руководство по безопасности RHEL5

На днях NSA (АНБ) опубликовало руководство по настройке безопасной конфигурации RHEL 5 (читай Fedora, Scientific Linux, CentOS, StartCom и т.д.). Руководство в формате PDF доступно здесь. В объеме 170 страниц изложены пошаговые рекомендации, затрагивающие множество вопросов, начиная с защиты системы в целом и заканчивая конкретными службами.

Настоящее Open Source пиво

Вчера на первом этаже магазина в Tate Modern впервые увидел FREE BEER (version 3.2) от Корнуэльской пивоварни St.Austell Brewery (кстати, рекомендую их Tribute). На этикетке значиться: FREE BEER is based on classic ale brewing traditions, but with addded Guarana for a natural energy boost. The recipe and branding elements of FREE BEER is published under a Creative Commons (Attribution-ShareAlike 2.5) license, which means that anyone can use the recipe to brew their own FREE BEER or create a derivative of the recipe. Во как!


Судя по информации с сайта, впервые пиво было представлено в Tate Modern еще летом этого года в качестве участника выставки «Социальные системы». Продается оно по ₤3.95 (свободный!=бесплатный). И на вкус оказалось совсем не плохим :) Кстати, на официальном сайте http://freebeer.org уже доступны «исходники» версии 3.4 :) Неплохая идея для пивных стартапов :)

Часть 2.2. SELinux. MLS и MCS: что с чем едят. MCS

Разберемся, что такое MCS и как ограничить пользователям (в том числе и администратору) доступ к информации при помощи категорий SELinux. Продолжаем разговор, начатый постами:

Часть 1. SELinux. Максимальный уровень защиты – бесплатно.
Часть 2.1. SELinux. MLS и MCS: что с чем едят. MLS.

Итак, если воспользоваться преимуществами многоуровневой системы безопасности (multilevel security - MLS) можно только при использовании «строгой» (strict) политики SELinux, то поддержка мульти-категорийной безопасности (MCS) доступна нам в «целевой» (targeted) политике, используемой по умолчанию. В качестве тестовой машины будем использовать RHEL 5.0, но, по большому счету, это не принципиально. Перечисленные базовые вещи должны одинаково работать на всех последних Fedora/RHEL/CentOS/etc, поставляемых с политикой, собранной из Reference Policy. Выполним команду

[root@dhcppc5 ~]$ seinfo | grep Cat
Sensitivities:       1    Categories:       1024

Мы видим, что нам доступно 1024 категории и один тип чувствительности данных. Что это означает? Вспомним, как выглядел контекст безопасности в FС4 и RHEL4:

user:role:type

Такого контекста безопасности вполне достаточно для организации контроля доступа средствами RBAC и TE. Впрочем, если говорить о работе с целевой политикой, где главный инструмент – TE, пользователь и роль нас особенно не интересует. В MLS политике (а рассматриваемая мульти-категорийная безопасность – это подмножество MLS) контекст расширен и включает два уровня безопасности (security level):

user:role:type: sensitivity[:category,…][- sensitivity[:category,…]]

Первым указывается обязательный текущий уровень (low или current), затем через символ дефиса – наивысший разрешенный уровень (high или clearance). Каждый из двух возможных уровней безопасности включает в себя обязательную часть – чувствительность (sensitivity) данных и ноль или больше категорий (category). Sensitivity в целевой политике всегда будет s0. Чувствительности данных, отличные от 0, зарезервированы для государственных и военных организаций и используются только в политике MLS («секретно», «совершенно секретно» и т.п.). Собственно, то, что нам доступен только один уровень чувствительности и 1024 возможных категорий, мы уже видели в выводе команды seinfo. Кстати, число категорий и чувствительностей данных можно поменять, если вы решите пересобрать политику из исходных кодов. Как и для перекомпиляции ядра, у вас должна быть весомая причина, чтобы этим заниматься. Политика SELinux - модульная, и чаще всего нам приходиться компилировать только отдельные модули. Далее мы не будем касаться работы с sensitivity, а сосредоточимся на категориях.

По умолчанию возможности MCS доступны, но не используются в целевой политике. Все файлы имеют чувствительность s0 и не имеют назначенных категорий. Поэтому если вы в выводе команды ls –Z не видите уровня безопасности, хотя и используете политику с поддержкой MCS, знайте, что он равен s0.

Категории обозначаются как с0, с1,… c1024. Для повседневной работы это не очень удобно. Для того чтобы можно было работать с «говорящими» категориями, в Fedora/RHEL по умолчанию запущен демон mcstransd. Он использует конфигурационный файл /etc/selinux/<имя_политики>/setrans.conf. Наиболее «правильным» способом работы с конфигурационными файлами SELinux является использование утилиты semanage, появившейся в Fedora Core 5.

Из man-страницы semanage(8):


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

Вводим команду, показывающую существующие имена уровней безопасности:

[root@dhcppc5 ~]# semanage translation -l
Level                     Translation
s0
s0-s0:c0.c1023            SystemLow-SystemHigh
s0:c0.c1023               SystemHigh

Как и ожидалось, напротив уровня безопасности s0 у нас пробелы, что мы собственно и видим при выводе команды ls –Z. При помощи команды semanege с ключевым словом translation и опциями -a, -d и -m можно добавлять, удалять и модифицировать имена категорий. Пока что после каждого изменения необходимо перезапускать демон mcstransd. В отличие от уровней чувствительности данных, категории не представляют собой иерархической структуры. Точка в синтаксисе обозначает диапазон категорий, запятая отделяет диапазоны и отдельные категории.

Теперь посмотрим, к каким категориям разрешен доступ пользователям:

[root@dhcppc5 ~]# semanage login -l

Login Name                SELinux User              MLS/MCS Range

__default__               user_u                    s0
root                      root                      SystemLow-SystemHigh

Рядовым пользователям по умолчанию разрешен доступ только к s0. Отлично, давайте добавим новую категорию.

[root@dhcppc5 ~]# semanage translation -a -T chaos s0:c20
[root@dhcppc5 ~]# service mcstrans restart

Добавим категорию пользователю. Обратите внимание, что сейчас мы работаем с пользователями Linux (ключевое слово команды login) а не SELinux (ключевое слово user)

[root@dhcppc5 ~]# semanage login -a -r chaos butters

Теперь можно зайти пользователем butters, создать файл в /tmp, и посмотреть, сможет ли пользователь, не имеющий доступ к категории chaos, прочитать этот файл:

[butters@dhcppc5 tmp]$ touch /tmp/butters_file

[cartman@dhcppc5 tmp]$ ls -Z /tmp/butters_file
-rw-rw-r--  butters butters user_u:object_r:tmp_t:chaos      /tmp/butters_file
[cartman@dhcppc5 tmp]$ cat /tmp/butters_file
cat: /tmp/butters_file: Permission denied

При этом в /var/log/audit/audit.log мы увидим сообщение:

type=AVC msg=audit(1194279634.604:130): avc: denied { read } for pid=10770 comm="cat" name="butters_file" dev=dm-0 ino=655970 scontext=user_u:system_r:unconfined_t:s0 tcontext=user_u:object_r:tmp_t:s0:c20 tclass=file

Кстати, если воспользоваться утилитой audit2allow:

[root@dhcppc5 ~]# cat /var/log/audit/audit.log | audit2allow -l
allow unconfined_t tmp_t:file read;

мы увидим, что с категориями она работать не умеет, а, значит, от чтения журналов нам все равно не уйти ;) Собственно, это и правильно. audit2allow в первую очередь предназначена для решения проблем с TE.

Можно удалить категорию chaos, чтобы позволить остальным доступ к файлу

[butters@dhcppc5 tmp]$ chcat -- -chaos butters_file

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

При проведении этого маленького эксперимента не пользуйтесь командой su. Заходите с новой консоли или по ssh. Дело в том, что su не меняет текущий SELinux-контекст пользователя:

[cartman@dhcppc5 tmp]$ su -
Password:
[root@dhcppc5 ~]# cat /tmp/butters_file
cat: /tmp/butters_file: Permission denied

Что теперь? А теперь мы используя нашу стандартную целевую политику, которая включена по умолчанию, мы можем запретить системному администратору просмотр не предназначенных для него файлов.

В двух словах идея такова:
1. Создаем специальную категорию и специальных пользователей (сотрудников отдела ИБ).
2. Даем доступ к специальной категории только этим специальным пользователям.
3. Присваиваем semanage эту категорию, а сотрудникам ИБ даем возможность запускать этот файл через sudo.
4. В зависимости от ситуации, также поступаем с chcon и chcat.
5. Закрываем пользователю root возможность зайти в систему. Ограничиваем физический доступ. Оставляем su.
6. Все равно остается ряд проблем :) Строгая и MLS политика в этой ситуации подходит лучше, но и описанный вариант – жизнеспособен.

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

Часть 2.1. SELinux. MLS и MCS: что с чем едят. MLS.

Продолжаем разговор, начатый постом «Часть 1. SELinux. Максимальный уровень защиты – бесплатно».

Вслед за сообщениями о сертификации Red Hat Enterprise Linux 5 по Common Criteria EAL4+ (c расширениями LSPP, RBACPP и CAPP) на серверах HP и IBM, компания HP объявила о начале предоставления услуги поддержки конфигурации RHEL с включенной многоуровневой системой безопасности (multilevel security -MLS).

Что здесь понимается под MLS? MLS – это еще одна форма принудительного контроля доступа (mandatory access control - MAC), доступная нам при использовании SELinux. Политика с поддержкой MLS является опциональной и для большинства пользователей она будет намного менее полезной, чем принудительный контроль на основе Type Enforcement (TE) – основного механизма, используемого в SELinux. Но MLS – это «пропуск» для операционной системы в государственные и военные организации, где без такого рода разграничения полномочий не обойтись.

Политика MLS базируется на формальной модели Bell-LaPadula. В терминах этой модели все субъекты (для простоты - процессы) и объекты (файлы) имеют свой уровень допуска. Субъект с определенным уровнем допуска имеет право читать и создавать (писать/обновлять) объекты с тем же уровнем допуска. Кроме того, он имеет право читать менее секретные объекты и создавать объекты с более высоким уровнем. Субъект никогда не сможет создавать объекты с уровнем допуска ниже, чем он сам имеет, а также прочесть объект более высокого уровня допуска.

Уффф… Надеюсь, я вас не запутал. По-английски это формулируется намного короче:
«write up, read down» и «no write down, no read up».

Для поддержки MLS традиционный контекст SELinux, состоящий из трех частей: пользователь, роль и тип, был дополнен уровнем допуска. Уровень допуска состоит из диапазонов чувствительности данных (например, «секретно», «ДСП») и категорий данных («отдел кадров», «отдел финансовой отчетности»). Подробно мы поговорим об уровнях доступа, когда речь зайдет о мульти-категорийной безопасности (MCS), которую можно использовать и в «умолчальной» целевой политике.

Переходим к техническим деталям реализации, а вернее – к эксперименту с их использованием. Как опциональная, политика MLS доступна начиная с Fedora Core 5. Именно тогда разработчики перешли с использования оригинальной Example Policy на Reference Policy от Tresys. MLS нельзя установить интерактивно через Anaconda (но можно установить при использовании kickstart-файла). На установленной системе даем команду

yum –y install selinux-policy-mls

Тем самым мы устанавливаем базовый модуль MLS, появившийся в RHEL третьим после «целевой» (targeted) и «строгой» (strict) политики. Собственно, этот третий вариант политики и появился в RHEL для соответствия сертификации EAL4+ LSPP. Данная политика поддерживает принудительный контроль доступа TE, RBAC, и, естественно, модель Bell-LaPadula. Далее нам нужно поправить /etc/sysconfig/selinux, сказав, что теперь используется наша новая политика MLS. Меняем policy=targeted на policy=mls. Теперь, поскольку все файлы на существующей ФС создавались во время работы «целевой» (targeted) политики, нам необходимо обновить SELinux-контексты для всех файлов. Самый простейший/правильный способ – команды

touch /.autorelabel; init 6

Когда появиться меню загрузчика GRUB, нажмите «a», и в конец строки, определяющей параметры загрузки ядра, добавьте enforcing=0. Это (естественно, только на время до перезагрузки) переведет SELinux в «разрешительный» режим, когда правила отрабатываются и файлы создаются с правильным контекстом безопасности, но ограничения, налагаемые политикой SELinux, не применяются. Нам это нужно для того, чтобы ничто не помешало обновить контекст безопасности файлов. Ваша система загрузиться так, если бы SELinux был отключен, и все контексты будут обновлены (если вы не ошиблись при наборе touch /.autorelabel) . Теперь настало время снова перезагрузится, но уже без параметра enforcing=0. Перед перезагрузкой убедитесь, что работает демон sshd. В принципе можно обойтись и без перезагрузки, зайдя в текстовую консоль как пользователь root и отдав команду


setenforce 1

Кстати, выбор политики и необходимость обновления контекста безопасности файлов во время перезагрузки можно произвести из GUI, используя system-config-selinux.



После перезагрузки зайдите на машину по ssh. Дает ли доступ к привилегиям команда su? А sudo? А получится ли перевести SELinux в «разрешительный» режим или вообще выключить? Нет. Попробуйте создать файл из-под учетной записи root, а потом простым пользователем посмотреть его метаданные командой ls. «Вместо строчки – только точки».
Также после перезагрузки вы уже не сможете работать с X Window (как не запустится и ряд других служб). Хотя бы из-за того, что будет существовать возможность скопировать информацию из окна терминала с высоким уровнем допуска в терминал с низким.

Привести свою тестовую (подчеркиваю, тестовую!) систему в исходное состояние вы сможете снова перегрузившись с параметром ядра enforcing=0 и выбрав «целевую» политику.

Написание «строгой» MLS политики весьма сложная и комплексная задача. И от версии к версии политика становиться более гибкой, охватывая большее число служб. Для простого пользователя многоуровневая безопасность – излишество. Для большинства задач достаточно того уровня безопасности, который достигается при использовании включенной по умолчанию «целевой» политики SELinux. Однако, и в рамках «целевой» политики можно использовать реализацию мульти-категорийной безопасности (MCS), о чем мы и поговорим в продолжении этого поста «Часть 2.2. SELinux. MLS и MCS: что с чем едят. MCS». А пока ждем выхода Fedora 8! ;)


Кстати, благодаря Dan Walsh, там уже должны появиться некоторые из моих переводов руководств по SELinux на русском.

История Англии: Window Tax

В последнее время увлекаюсь изучением истории Англии. Так вот, знаете ли вы, что словосочетание «налог на окна» («Window Tax», или, как следует из Wikipedia, иногда - «Microsoft Tax»), которое у «айтишников» ассоциируется с необходимостью платить за пре-инсталлированную OEM-версию операционной системы, поставляемую вместе с ПК, даже если вы не собираетесь ее использовать, это – реально существовавший когда-то налог.


Этот налог был введен в 1696 королем Вильгельмом III, и отменен только лишь в 1851 году (год Всемирной Промышленной Выставки). Смысл кажущегося сейчас абсурдным большинству людей налога в том, что чем больше у вас окон в доме, тем больший налог вы платите. Доходило до того, что домовладельцы специально заколачивали в домах часть окон, а в Эдинбурге так и вовсе был построен квартал с домами без окон.

Впрочем, и современный «налог на окна» некоторые считают абсурдным и ухудшающим конкуренцию в соответствующем сегменте рынка.