Глава 18. Принудительное управление доступом (MAC)

Этот перевод может быть устаревшим. Для того, чтобы помочь с переводом, пожалуйста, обратитесь к Сервер переводов FreeBSD.

Содержание

18.1. Обзор

FreeBSD поддерживает расширения безопасности, основанные на документах POSIX®.1e. Эти механизмы безопасности включают списки контроля доступа к файловой системе (“Списки контроля доступа”) и принудительный контроль доступа (MAC). MAC позволяет загружать модули контроля доступа для реализации политик безопасности. Некоторые модули обеспечивают защиту узкого подмножества системы, укрепляя определённую службу. Другие предоставляют всеобъемлющую безопасность с метками на всех субъектах и объектах. Обязательная часть определения указывает на то, что применение контроля осуществляется администраторами и операционной системой. Это отличается от механизма безопасности по умолчанию — обычного контроля доступа (Discretionary Access Control, DAC), где применение контроля остаётся на усмотрение пользователей.

Эта глава посвящена инфраструктуре MAC и набору модулей политики безопасности, предоставляемых FreeBSD для включения различных механизмов безопасности.

Прочитайте эту главу, чтобы узнать:

Терминология, связанная с инфраструктурой MAC.
Возможности модулей политики безопасности MAC, а также разница между политикой с метками и без меток.
Соображения, которые необходимо учитывать перед настройкой системы для использования инфраструктуры MAC.
Какие модули политики безопасности MAC включены в FreeBSD и как их настроить.
Как реализовать более безопасную среду с использованием инфраструктуры MAC.
Как проверить конфигурацию MAC, чтобы убедиться в правильном использовании инфраструктуры.

Прежде чем читать эту главу, необходимо:

Понимать основы UNIX® и FreeBSD (Основы FreeBSD).
Иметь некоторое представление о безопасности и о том, как она относится к FreeBSD (Безопасность).

Неправильная настройка MAC может привести к потере доступа к системе, недовольству пользователей или невозможности использования функций, предоставляемых Xorg. Важно отметить, что нельзя полагаться исключительно на MAC для полной защиты системы. Инфраструктура MAC лишь дополняет существующую политику безопасности. Без грамотных мер безопасности и регулярных проверок система никогда не будет полностью защищена.

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

Хотя в этой главе рассматривается широкий спектр вопросов безопасности, связанных с инфраструктурой MAC, разработка новых модулей политики безопасности MAC не будет освещена. Ряд модулей политики безопасности, включенных в фреймворк MAC, обладают специфическими характеристиками, которые предоставляются как для тестирования, так и для разработки новых модулей. Дополнительную информацию об этих модулях политики безопасности и предоставляемых ими механизмах можно найти в mac_test(4), mac_stub(4) и mac_none(4).

18.2. Ключевые термины

В документации FreeBSD при обращении к инфраструктуре MAC используются следующие ключевые термины:

компартмент (compartment): набор программ и данных, которые должны быть разделены или изолированы, при этом пользователи получают явный доступ к определенным компонентам системы. Компартмент представляет собой группу, такую как рабочая группа, отдел, проект или тема. Компартменты позволяют реализовать политику безопасности на основе принципа "необходимо знать".
целостность (integrity): уровень доверия, который может быть оказан данным. По мере повышения целостности данных возрастает и возможность доверять этим данным.
уровень (level): увеличенное или уменьшенное значение атрибута безопасности. По мере повышения уровня его безопасность также считается более высокой.
метка (label): атрибут безопасности, который может быть применён к файлам, каталогам или другим элементам системы. Его можно рассматривать как штамп конфиденциальности. Когда метка назначается файлу, она описывает его свойства безопасности и разрешает доступ только файлам, пользователям и ресурсам с аналогичными настройками безопасности. Значение и интерпретация меток зависят от конфигурации политики. Некоторые политики рассматривают метку как показатель целостности или секретности объекта, тогда как другие могут использовать метки для хранения правил доступа.
множественные метки (multilabel): это свойство является параметром файловой системы, которое можно установить в однопользовательском режиме с помощью tunefs(8), во время загрузки с использованием fstab(5) или при создании новой файловой системы. Эта опция позволяет администратору применять различные метки MAC к разным объектам. Данная опция применяется только к модулям политики безопасности, которые поддерживают маркировку метками (далее — маркировку).
одиночная метка (single label): политика, при которой вся файловая система использует одну метку для контроля доступа к потокам данных. Если параметр multilabel не установлен, все файлы будут соответствовать одной и той же настройке метки.
объект (object): сущность, через которую информация передаётся под управлением субъекта. Это включает каталоги, файлы, поля, экраны, клавиатуры, память, магнитные накопители, принтеры или любые другие устройства хранения или передачи данных. Объект является контейнером данных или системным ресурсом. Доступ к объекту фактически означает доступ к его данным.
субъект (subject): любая активная сущность, вызывающая передачу информации между объектами, например, пользователь, пользовательский процесс или системный процесс. В FreeBSD это почти всегда поток, действующий в процессе от имени пользователя.
политика (policy): набор правил, определяющий, как достичь поставленных целей. Политика обычно документирует, каким образом следует обращаться с определёнными элементами. В этой главе под политикой понимается набор правил, контролирующих поток данных и информации, а также определяющих, кто имеет доступ к этим данным и информации.
верхний уровень (high-watermark): этот тип политики позволяет повышать уровни безопасности для доступа к информации более высокого уровня. В большинстве случаев исходный уровень восстанавливается после завершения процесса. В настоящее время в инфраструктуре MAC в FreeBSD отсутствует такой тип политики.
нижний уровень (low-watermark): этот тип политики позволяет понижать уровни безопасности для доступа к информации с более низким уровнем защиты. В большинстве случаев исходный уровень безопасности пользователя восстанавливается после завершения процесса. Единственный модуль политики безопасности в FreeBSD, использующий этот подход, — это mac_lomac(4).
_ чувствительность (sensivity)_: обычно используется при обсуждении Многоуровневой Безопасности (Multilevel Security, MLS). Уровень чувствительности описывает, насколько важными или секретными должны быть данные. По мере увеличения уровня чувствительности возрастает и важность секретности, или конфиденциальности, данных.

18.3. Метки MAC

Метка MAC — это атрибут безопасности, который может быть применён к субъектам и объектам в системе. При установке метки администратор должен понимать её последствия, чтобы избежать неожиданного или нежелательного поведения системы. Доступные атрибуты объекта зависят от загруженного модуля политики, так как модули политики интерпретируют свои атрибуты по-разному.

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

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

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

Политика с одной меткой несколько похожа на DAC, поскольку root настраивает политики так, чтобы пользователи попадали в соответствующие категории и уровни доступа. Заметное отличие заключается в том, что многие модули политики также могут ограничивать пользователя root. Базовый контроль над объектами затем передаётся группе, но root может отозвать или изменить настройки в любое время.

Когда это уместно, политику с несколькими метками можно установить на файловой системе UFS, передав multilabel в tunefs(8). Политика с несколькими метками позволяет каждому субъекту или объекту иметь свою собственную независимую метку MAC. Решение использовать политику с несколькими метками или одной меткой требуется только для политик, реализующих функцию маркировки, таких как biba, lomac и mls. Некоторые политики, такие как seeotheruids, portacl и partition, вообще не используют метки.

Использование политики с несколькими метками на разделе и установление модели безопасности с несколькими метками может увеличить административную нагрузку, так как всё в этой файловой системе имеет метку. Это включает каталоги, файлы и даже узлы устройств.

Следующая команда установит multilabel для указанной файловой системы UFS. Это можно сделать только в однопользовательском режиме и не является обязательным для файловой системы подкачки:

# tunefs -l enable /

Некоторые пользователи столкнулись с проблемами при установке флага multilabel на корневом разделе. Если это ваш случай, ознакомьтесь с Устранение неполадок инфраструктуры MAC.

Поскольку политика с несколькими метками устанавливается для каждой файловой системы, она может не потребоваться, если структура файловых систем хорошо продумана. Рассмотрим пример модели безопасности MAC для веб-сервера FreeBSD. На этой машине используется единая метка biba/high для всего в стандартных файловых системах. Если веб-сервер должен работать с biba/low, чтобы предотвратить возможность записи вверх, его можно установить в отдельную файловую систему UFS /usr/local с меткой biba/low.

18.3.1. Конфигурация меток

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

Вся настройка может быть выполнена с помощью setfmac, который используется для установки меток MAC на объектах системы, и setpmac, который используется для установки меток на субъектах системы. Например, чтобы установить метку MAC biba в значение high для test:

# setfmac biba/high test

Если конфигурация выполнена успешно, командная строка вернётся без ошибок. Частая ошибка — Permission denied, которая обычно возникает при установке или изменении метки на защищённом объекте. Другие условия могут вызывать иные сбои. Например, файл может не принадлежать пользователю, пытающемуся изменить метку объекта, объект может не существовать или быть доступным только для чтения. Обязательная политика не позволит процессу изменить метку файла, возможно, из-за свойств самого файла, процесса или предлагаемого нового значения метки. Например, если пользователь с низким уровнем целостности попытается изменить метку файла с высоким уровнем целостности или если пользователь с низким уровнем целостности попытается изменить метку файла с низкого уровня на высокий, эти операции завершатся неудачей.

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

# setfmac biba/high test
Permission denied
# setpmac biba/low setfmac biba/high test
# getfmac test
test: biba/high

Для уже запущенных процессов, таких как sendmail, обычно используется getpmac вместо этого. Эта команда принимает идентификатор процесса (PID) вместо имени команды. Если пользователи пытаются работать с файлом, к которому у них нет доступа, в соответствии с правилами загруженных модулей политики, будет отображаться ошибка Операция не разрешена (Operation not permitted).

18.3.2. Предопределенные метки

Несколько модулей политики FreeBSD, поддерживающих функцию меток, предлагают три предопределённых метки: low, equal и high, где:

low считается минимальным уровнем метки, который может быть установлен для объекта или субъекта. Установка этого уровня для объектов или субъектов блокирует их доступ к объектам или субъектам, помеченным как high.
equal устанавливает, что субъект или объект отключён или не затронут, и должен использоваться только для объектов, считающихся исключёнными из политики.
high предоставляет объекту или субъекту наивысший уровень доступа, доступный в модулях политик Biba и MLS.

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

18.3.3. Числовые метки

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

biba/10:2+3+6(5:2+3-20:2+3+4+5+6)

может интерпретироваться как "Метка/уровень целостности (grade) политики Biba 10: компартменты 2, 3 и 6: (уровень 5 …)"

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

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

Уровни целостности и компартменты в паре субъект-объект используются для построения отношения, известного как доминирование, при котором субъект доминирует над объектом, объект доминирует над субъектом, ни один не доминирует над другим или оба доминируют друг над другом. Случай «оба доминируют» возникает, когда две метки равны. В силу природы информационных потоков в модели Biba пользователь имеет права на набор компартментов, которые могут соответствовать проектам, но объекты также имеют набор компартментов. Пользователям может потребоваться ограничить свои права с помощью su или setpmac, чтобы получить доступ к объектам в компартментах, от которой они не ограничены.

18.3.4. Пользовательские метки

Пользователи должны иметь метки, чтобы их файлы и процессы корректно взаимодействовали с политикой безопасности, определенной в системе. Это настраивается в /etc/login.conf с использованием классов входа. Каждый модуль политики, использующий метки, будет реализовывать настройку класса пользователя.

Чтобы установить метку класса пользователя по умолчанию, которая будет применяться MAC, добавьте запись label. Ниже приведен пример записи label, содержащей каждый модуль политики. Обратите внимание, что в реальной конфигурации администратор никогда не включает все модули политики. Рекомендуется ознакомиться с остальной частью этой главы перед внедрением любой конфигурации.

default:\
	:copyright=/etc/COPYRIGHT:\
	:welcome=/etc/motd:\
	:setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\
	:path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:\
	:manpath=/usr/share/man /usr/local/man:\
	:nologin=/usr/sbin/nologin:\
	:cputime=1h30m:\
	:datasize=8M:\
	:vmemoryuse=100M:\
	:stacksize=2M:\
	:memorylocked=4M:\
	:memoryuse=8M:\
	:filesize=8M:\
	:coredumpsize=8M:\
	:openfiles=24:\
	:maxproc=32:\
	:priority=0:\
	:requirehome:\
	:passwordtime=91d:\
	:umask=022:\
	:ignoretime@:\
	:label=partition/13,mls/5,biba/10(5-15),lomac/10[2]:

Хотя пользователи не могут изменить значение по умолчанию, они могут изменить свою метку после входа в систему, в соответствии с ограничениями политики. В приведённом выше примере политика Biba указывает, что минимальный уровень целостности процесса — 5, максимальный — 15, а эффективная метка по умолчанию — 10. Процесс будет выполняться с меткой 10, пока не решит изменить её, например, если пользователь воспользуется setpmac, что будет ограничено политикой Biba в рамках заданного диапазона.

После любого изменения в файле login.conf необходимо перестроить базу данных возможностей классов входа с помощью команды cap_mkdb.

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

18.3.5. Метки сетевых интерфейсов

Метки могут быть установлены на сетевых интерфейсах для помощи в контроле потока данных в сети. Политики, использующие метки сетевых интерфейсов, работают так же, как политики, применяемые к объектам. Например, пользователи с высокими уровнями в Biba не смогут получить доступ к сетевым интерфейсам с меткой low.

При установке MAC-метки на сетевых интерфейсах, maclabel может быть передан в ifconfig:

# ifconfig bge0 maclabel biba/equal

Этот пример установит метку MAC biba/equal на интерфейсе bge0. При использовании настройки вида biba/high(low-high) всю метку следует заключить в кавычки, чтобы избежать ошибки.

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

18.4. Планирование конфигурации безопасности

Прежде чем внедрять какие-либо политики MAC, рекомендуется этап планирования. На этапе планирования администратор должен учесть требования и цели внедрения, такие как:

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

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

Рассмотрим, как инфраструктура MAC усиливает безопасность системы в целом. Различные модули политики безопасности, предоставляемые инфраструктурой MAC, могут использоваться для защиты сети и файловых систем или для блокировки доступа пользователей к определённым портам и сокетам. Возможно, наилучшее применение модулей политики — это загрузка нескольких модулей политики безопасности одновременно для создания среды MLS. Такой подход отличается от политики усиления защиты, которая обычно укрепляет элементы системы, используемые только для определённых целей. Недостатком MLS является увеличение административных затрат.

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

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

Обязанностью системного администратора является тщательный выбор подходящих модулей политики безопасности. Для среды, где требуется ограничить контроль доступа по сети, модули политик mac_portacl(4), mac_ifoff(4) и mac_biba(4) могут стать хорошей отправной точкой. В среде, где необходима строгая конфиденциальность объектов файловой системы, следует рассмотреть модули политик mac_bsdextended(4) и mac_mls(4).

Решения о политиках могут приниматься на основе конфигурации сети. Если только определенные пользователи должны иметь доступ к ssh(1), модуль политики mac_portacl(4) является хорошим выбором. В случае файловых систем доступ к объектам может считаться конфиденциальным для одних пользователей, но не для других. Например, большая команда разработчиков может быть разделена на меньшие проекты, где разработчики из проекта A не должны иметь доступа к объектам, созданным разработчиками из проекта B. Однако оба проекта могут нуждаться в доступе к объектам, созданным разработчиками из проекта C. Используя различные модули политик безопасности, предоставляемые MAC-фреймворком, пользователи могут быть разделены на эти группы и затем получить доступ к соответствующим объектам.

Каждый модуль политики безопасности имеет уникальный способ обработки общей безопасности системы. Выбор модуля должен основываться на продуманной политике безопасности, которая может потребовать пересмотра и повторной реализации. Понимание различных модулей политики безопасности, предоставляемых инфраструктурой MAC, поможет администраторам выбрать наилучшие политики для их ситуаций.

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

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

18.5. Доступные политики MAC

Стандартное ядро FreeBSD включает options MAC. Это означает, что каждый модуль, входящий в состав инфраструктуры MAC, может быть загружен с помощью kldload как модуль ядра во время выполнения. После тестирования модуля добавьте его имя в /boot/loader.conf, чтобы он загружался при старте системы. Каждый модуль также предоставляет опцию ядра для администраторов, которые предпочитают компилировать собственное ядро системы.

FreeBSD включает набор политик, которые охватывают большинство требований безопасности. Каждая политика кратко описана ниже. Последние три политики поддерживают целочисленные настройки вместо трёх стандартных меток.

18.5.1. Политика MAC — See Other UIDs

Название модуля: mac_seeotheruids.ko

Строка конфигурации ядра: options MAC_SEEOTHERUIDS

Опция загрузки: mac_seeotheruids_load="YES"

Модуль mac_seeotheruids(4) расширяет настройки security.bsd.see_other_uids и security.bsd.see_other_gids sysctl. Эта опция не требует предварительной установки меток для настройки и может работать прозрачно с другими модулями.

После загрузки модуля следующие настройки sysctl могут быть использованы для управления его функциями:

security.mac.seeotheruids.enabled включает модуль и реализует настройки по умолчанию, которые запрещают пользователям возможность просматривать процессы и сокеты, принадлежащие другим пользователям.
security.mac.seeotheruids.specificgid_enabled позволяет исключить указанные группы из действия этой политики. Чтобы исключить определённые группы, используйте параметр security.mac.seeotheruids.specificgid=XXX sysctl, заменив XXX на числовой идентификатор группы, которую нужно исключить.
security.mac.seeotheruids.primarygroup_enabled используется для исключения определённых первичных групп из этой политики. При использовании этого параметра security.mac.seeotheruids.specificgid_enabled не может быть установлен.

18.5.2. Политика MAC — BSD Extended

Имя модуля: mac_bsdextended.ko

Строка конфигурации ядра: options MAC_BSDEXTENDED

Параметр загрузки: mac_bsdextended_load="YES"

Модуль mac_bsdextended(4) обеспечивает файловый межсетевой экран. Он расширяет стандартную модель прав доступа к файловой системе, позволяя администратору создавать набор правил, подобный межсетевому экрану, для защиты файлов, утилит и каталогов в иерархии файловой системы. При попытке доступа к объекту файловой системы происходит перебор списка правил до тех пор, пока не будет найдено соответствующее правило или не будет достигнут конец списка. Это поведение можно изменить с помощью параметра security.mac.bsdextended.firstmatch_enabled. Подобно другим модулям межсетевого экрана в FreeBSD, файл с правилами контроля доступа может быть создан и прочитан системой во время загрузки с использованием переменной rc.conf(5).

Список правил может быть введён с помощью ugidfw(8), синтаксис которого похож на ipfw(8). Дополнительные инструменты могут быть написаны с использованием функций из библиотеки libugidfw(3).

После загрузки модуля mac_bsdextended(4) для просмотра текущей конфигурации правил можно использовать следующую команду:

# ugidfw list
0 slots, 0 rules

По умолчанию никакие правила не определены, и доступ полностью открыт. Чтобы создать правило, которое блокирует доступ для всех пользователей, кроме root:

# ugidfw add subject not uid root new object not uid root mode n

Хотя это правило просто реализовать, это очень плохая идея, так как оно блокирует всех пользователей от выполнения любых команд. Более реалистичный пример запрещает user1 любой доступ, включая просмотр каталогов, к домашнему каталогу user2:

# ugidfw set 2 subject uid user1 object uid user2 mode n
# ugidfw set 3 subject uid user1 object gid user2 mode n

Вместо user1 можно использовать not uid user2, чтобы применять одинаковые ограничения доступа для всех пользователей. Однако пользователь root не подвержен влиянию этих правил.

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

18.5.3. Политика MAC — подавление интерфейсов

Имя модуля: mac_ifoff.ko

Строка конфигурации ядра: options MAC_IFOFF

Параметр загрузки: mac_ifoff_load="YES"

Модуль mac_ifoff(4) используется для отключения сетевых интерфейсов на лету и предотвращения их включения во время загрузки системы. Он не использует метки и не зависит от других модулей MAC.

Большая часть управления этим модулем осуществляется через следующие настраиваемые параметры sysctl:

security.mac.ifoff.lo_enabled включает или отключает весь трафик на интерфейсе loopback, lo(4).
security.mac.ifoff.bpfrecv_enabled включает или отключает весь трафик на интерфейсе Berkeley Packet Filter, bpf(4).
security.mac.ifoff.other_enabled включает или отключает трафик на всех остальных интерфейсах.

Одним из наиболее распространённых применений mac_ifoff(4) является мониторинг сети в среде, где сетевой трафик не должен разрешаться во время последовательности загрузки. Другое применение — написание скрипта, который использует приложение, например security/aide, для автоматической блокировки сетевого трафика при обнаружении новых или изменённых файлов в защищённых каталогах.

18.5.4. Политика MAC - списки управления доступом к портам

Имя модуля: mac_portacl.ko

Строка конфигурации ядра: MAC_PORTACL

Параметр загрузки: mac_portacl_load="YES"

Модуль mac_portacl(4) используется для ограничения привязки к локальным TCP- и UDP-портам, позволяя непривилегированным пользователям (не root) привязываться к указанным привилегированным портам ниже 1024.

После загрузки этот модуль включает политику MAC для всех сокетов. Доступны следующие настраиваемые параметры:

security.mac.portacl.enabled включает или отключает политику полностью.
security.mac.portacl.port_high устанавливает наибольший номер порта, который защищает mac_portacl(4).
security.mac.portacl.suser_exempt при установке в ненулевое значение освобождает пользователя root от действия данной политики.
security.mac.portacl.rules задаёт политику в виде текстовой строки формата правило[,правило,…], с любым необходимым количеством правил, где каждое правило имеет вид тип_идентификатора:идентификатор:протокол:порт. тип_идентификатора может быть uid или gid. Параметр протокол ` принимает значения `tcp или udp. Параметр порт указывает номер порта, к которому разрешено привязываться указанному пользователю или группе. Для параметров идентификатор пользователя, идентификатор группы и порт можно использовать только числовые значения.

По умолчанию порты ниже 1024 могут использоваться только привилегированными процессами, работающими от имени root. Чтобы разрешить непривилегированным процессам привязываться к портам ниже 1024 с помощью mac_portacl(4), задайте следующие настраиваемые параметры следующим образом:

# sysctl security.mac.portacl.port_high=1023
# sysctl net.inet.ip.portrange.reservedlow=0
# sysctl net.inet.ip.portrange.reservedhigh=0

Чтобы предотвратить влияние этой политики на пользователя root, установите security.mac.portacl.suser_exempt в ненулевое значение.

# sysctl security.mac.portacl.suser_exempt=1

Чтобы пользователь www с UID 80 мог привязываться к порту 80 без необходимости в привилегиях root:

# sysctl security.mac.portacl.rules=uid:80:tcp:80

Следующий пример разрешает пользователю с UID 1001 привязываться к TCP-портам 110 (POP3) и 995 (POP3s):

# sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995

18.5.5. Политика MAC — разделы процессов

Имя модуля: mac_partition.ko

Строка конфигурации ядра: options MAC_PARTITION

Опция загрузки: mac_partition_load="YES"

Политика mac_partition(4) помещает процессы в определенные "разделы" на основе их метки MAC. Большая часть настройки этой политики выполняется с помощью setpmac(8). Для этой политики доступна одна настраиваемая переменная sysctl:

security.mac.partition.enabled включает принудительное применение разделов процессов MAC.

Когда эта политика включена, пользователи смогут видеть только свои процессы и процессы в своем разделе, но не смогут работать с утилитами за пределами этого раздела. Например, пользователь из класса insecure не сможет получить доступ к top, а также ко многим другим командам, которые должны запускать процессы.

В этом примере top добавляется к набору меток пользователей в классе insecure. Все процессы, запущенные пользователями из класса insecure, останутся с меткой partition/13.

# setpmac partition/13 top

Эта команда отображает метку раздела и список процессов:

# ps Zax

Эта команда отображает метку раздела процессов другого пользователя и его текущие запущенные процессы:

# ps -ZU trhodes

Пользователи могут видеть процессы с меткой root, если не загружена политика mac_seeotheruids(4).

18.5.6. Модуль многоуровневой безопасности MAC

Имя модуля: mac_mls.ko

Строка конфигурации ядра: options MAC_MLS

Параметр загрузки: mac_mls_load="YES"

Политика mac_mls(4) контролирует доступ между субъектами и объектами в системе, применяя строгую политику управления потоком информации.

В средах MLS в метке каждого субъекта или объекта устанавливается уровень "допуска" вместе с компартментами. Поскольку эти уровни допуска могут достигать значений, превышающих несколько тысяч, тщательная настройка каждого субъекта или объекта была бы сложной задачей. Для снижения административной нагрузки в эту политику включены три метки: mls/low, mls/equal и mls/high, где:

Все объекты, помеченные меткой mls/low, будут иметь низкий уровень доступа и не смогут обращаться к информации более высокого уровня. Эта метка также предотвращает запись или передачу информации от объектов с более высоким уровнем доступа к объектам с более низким уровнем.
mls/equal следует размещать на объектах, которые должны быть освобождены от политики.
mls/high — это наивысший возможный уровень допуска. Объекты с этой меткой будут доминировать над всеми остальными объектами в системе; однако они не допустят утечки информации к объектам более низкого класса.

MLS предоставляет:

Иерархический уровень безопасности с набором неиерархических категорий.
Фиксированные правила нет чтения вверх, нет записи вниз. Это означает, что субъект может иметь право чтения объектов на своём уровне или ниже, но не выше. Аналогично, субъект может иметь право записи объектов на своём уровне или выше, но не ниже.
Секретность, или предотвращение несанкционированного раскрытия данных.
Основы проектирования систем, которые одновременно обрабатывают данные с разными уровнями конфиденциальности, не допуская утечки информации между секретными и конфиденциальными данными.

Доступны следующие настраиваемые параметры sysctl:

security.mac.mls.enabled используется для включения или отключения политики MLS.
security.mac.mls.ptys_equal помечает все устройства pty(4) как mls/equal при создании.
security.mac.mls.revocation_enabled отзывает доступ к объектам после изменения их метки на метку более низкого уровня целостности.
security.mac.mls.max_compartments устанавливает максимальное количество уровней компартментов, разрешенных в системе.

Для работы с метками MLS используйте setfmac(8). Чтобы назначить метку объекту:

# setfmac mls/5 test

Чтобы получить метку MLS для файла test:

# getfmac test

Другой подход заключается в создании основного файла политики в /etc/, который определяет информацию о политике MLS, и передаче этого файла в setfmac.

При использовании модуля политики MLS администратор планирует контролировать поток конфиденциальной информации. Значение по умолчанию block read up block write down устанавливает всё в состояние low. Вся информация доступна, и администратор постепенно повышает её конфиденциальность.

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

Некоторые примеры ситуаций для модуля политики MLS включают веб-сервер электронной коммерции, файловый сервер с критически важной информацией компании и среды финансовых учреждений.

18.5.7. Модуль MAC Biba

Имя модуля: mac_biba.ko

Строка конфигурации ядра: options MAC_BIBA

Опция загрузки: mac_biba_load="YES"

Модуль mac_biba(4) загружает политику MAC Biba. Эта политика похожа на политику MLS, за исключением того, что правила передачи информации слегка изменены в обратном порядке. Это предотвращает поток конфиденциальной информации вниз, тогда как политика MLS предотвращает поток конфиденциальной информации вверх.

В средах Biba для каждого субъекта или объекта устанавливается метка «целостности». Эти метки состоят из иерархических уровней целостности и неиерархических компонентов. По мере повышения уровня увеличивается и его целостность.

Поддерживаемые метки: biba/low, biba/equal и biba/high, где:

biba/low считается самой низкой целостностью, которую может иметь объект или субъект. Установка этого уровня на объекты или субъекты блокирует их запись в объекты или субъекты с меткой biba/high, но не предотвращает чтение.
biba/equal следует размещать только на объектах, которые считаются исключёнными из политики.
biba/high разрешает запись в объекты с более низкой меткой, но запрещает чтение этих объектов. Рекомендуется устанавливать эту метку для объектов, которые влияют на целостность всей системы.

Biba обеспечивает:

Иерархические уровни целостности с набором неиерархических категорий целостности.
Фиксированные правила — это нет записи вверх, нет чтения вниз, что противоположно MLS. Субъект может иметь право записи в объекты на своём уровне или ниже, но не выше. Аналогично, субъект может иметь право чтения объектов на своём уровне или выше, но не ниже.
Целостность за счет предотвращения нежелательного изменения данных.
Уровни целостности вместо уровней чувствительности MLS.

Следующие настраиваемые параметры могут быть использованы для управления политикой Biba:

security.mac.biba.enabled используется для включения или отключения принудительного применения политики Biba на целевой машине.
security.mac.biba.ptys_equal используется для отключения политики Biba на устройствах pty(4).
security.mac.biba.revocation_enabled принудительно отзывает доступ к объектам, если их метка изменяется так, чтобы доминировать над субъектом.

Для доступа к настройкам политики Biba для системных объектов используйте setfmac и getfmac:

# setfmac biba/low test
# getfmac test
test: biba/low

Целостность, которая отличается от конфиденциальности, используется для гарантии того, что информация не будет изменена ненадёжными сторонами. Это включает информацию, передаваемую между субъектами и объектами. Она обеспечивает пользователям возможность изменять или получать доступ только к той информации, к которой у них есть явный доступ. Модуль политики безопасности mac_biba(4) позволяет администратору настроить, какие файлы и программы пользователь может просматривать и запускать, гарантируя, что эти программы и файлы считаются системой доверенными для данного пользователя.

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

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

18.5.8. Модуль MAC Low-watermark (нижний порог)

Имя модуля: mac_lomac.ko

Строка конфигурации ядра: options MAC_LOMAC

Параметр загрузки: mac_lomac_load="YES"

В отличие от политики MAC Biba, политика mac_lomac(4) разрешает доступ к объектам с более низким уровнем целостности только после понижения уровня целостности, чтобы не нарушать правила целостности.

Политика целостности Low-watermark работает почти идентично Biba, за исключением использования плавающих меток для поддержки понижения уровня субъекта через компартмент с вспомогательным уровнем целостности. Этот вторичный компартмент имеет вид [auxgrade]. При назначении политики с вспомогательным уровнем целостности используйте синтаксис lomac/10[2], где 2 — это вспомогательный уровень целостности.

Данная политика основывается на повсеместной маркировке всех системных объектов метками целостности, позволяя субъектам читать из объектов с низкой целостностью, а затем понижая уровень метки на субъекте с помощью [auxgrade], чтобы предотвратить последующие записи в объекты с высокой целостностью. Эта политика может обеспечить большую совместимость и потребовать меньше начальной настройки по сравнению с Biba.

Как и в политиках Biba и MLS, setfmac и setpmac используются для назначения меток объектам системы:

# setfmac /usr/home/trhodes lomac/high[low]
# getfmac /usr/home/trhodes lomac/high[low]

Вспомогательный уровень целостности low — это функция, предоставляемая только политикой MACLOMAC.

18.6. Блокировка пользователя

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

Для данного сценария модули политик mac_bsdextended(4) и mac_seeotheruids(4) могут сосуществовать и блокировать доступ к системным объектам, скрывая при этом пользовательские процессы.

Начните с добавления следующей строки в /boot/loader.conf:

mac_seeotheruids_load="YES"

Модуль политики безопасности mac_bsdextended(4) может быть активирован добавлением следующей строки в /etc/rc.conf:

ugidfw_enable="YES"

Файл с правилами по умолчанию, хранящийся в /etc/rc.bsdextended, будет загружен при инициализации системы. Однако стандартные записи могут потребовать изменения. Поскольку предполагается, что данная машина будет обслуживать только пользователей, все строки можно оставить закомментированными, за исключением последних двух, чтобы обеспечить принудительную загрузку системных объектов, принадлежащих пользователям, по умолчанию.

Добавьте необходимых пользователей на эту машину и перезагрузитесь. Для тестирования попробуйте войти в систему под разными пользователями на двух консолях. Выполните ps -aux, чтобы проверить, видны ли процессы других пользователей. Убедитесь, что выполнение ls(1) для домашнего каталога другого пользователя завершается ошибкой.

Не пытайтесь проводить тестирование от пользователя root, если специальные параметры sysctl не были изменены для блокировки доступа суперпользователя.

При добавлении нового пользователя его правило mac_bsdextended(4) не будет в списке набора правил. Чтобы быстро обновить набор правил, выгрузите модуль политики безопасности и загрузите его снова с помощью kldunload(8) и kldload(8).

18.7. Nagios в MAC клетке

В этом разделе показаны шаги, необходимые для внедрения системы мониторинга сети Nagios в среде MAC. Это пример, который требует от администратора проверки соответствия реализованной политики требованиям безопасности сети перед использованием в рабочей среде.

Этот пример требует установки multilabel на каждой файловой системе. Также предполагается, что net-mgmt/nagios-plugins, net-mgmt/nagios и www/apache22 установлены, настроены и корректно работают до попытки интеграции в инфраструктуре MAC.

18.7.1. Создайте небезопасный класс пользователя

Начните процедуру, добавив следующий класс пользователя в /etc/login.conf:

insecure:\
:copyright=/etc/COPYRIGHT:\
:welcome=/etc/motd:\
:setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\
:path=~/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
:manpath=/usr/share/man /usr/local/man:\
:nologin=/usr/sbin/nologin:\
:cputime=1h30m:\
:datasize=8M:\
:vmemoryuse=100M:\
:stacksize=2M:\
:memorylocked=4M:\
:memoryuse=8M:\
:filesize=8M:\
:coredumpsize=8M:\
:openfiles=24:\
:maxproc=32:\
:priority=0:\
:requirehome:\
:passwordtime=91d:\
:umask=022:\
:ignoretime@:\
:label=biba/10(10-10):

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

:label=biba/high:

Сохраните изменения и выполните следующую команду для перестроения базы данных:

# cap_mkdb /etc/login.conf

18.7.2. Настройте пользователей

Установите пользователя root в класс по умолчанию с помощью:

# pw usermod root -L default

Все пользовательские учетные записи, кроме root, теперь требуют указания класса входа. Класс входа обязателен, в противном случае пользователям будет отказано в доступе к распространённым командам. Следующий скрипт на sh должен помочь:

# for x in `awk -F: '($3 >= 1001) && ($3 != 65534) { print $1 }' \
	/etc/passwd`; do pw usermod $x -L default; done;

Затем добавьте учетные записи nagios и www в класс insecure:

# pw usermod nagios -L insecure
# pw usermod www -L insecure

18.7.3. Создайте файл контекстов

Файл контекстов теперь должен быть создан как /etc/policy.contexts:

# This is the default BIBA policy for this system.

# System:
/var/run(/.*)?			biba/equal

/dev/(/.*)?			biba/equal

/var				biba/equal
/var/spool(/.*)?		biba/equal

/var/log(/.*)?			biba/equal

/tmp(/.*)?			biba/equal
/var/tmp(/.*)?			biba/equal

/var/spool/mqueue		biba/equal
/var/spool/clientmqueue		biba/equal

# For Nagios:
/usr/local/etc/nagios(/.*)?	biba/10

/var/spool/nagios(/.*)?		biba/10

# For apache
/usr/local/etc/apache(/.*)?	biba/10

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

Этот файл будет прочитан после выполнения setfsmac для каждой файловой системы. В этом примере устанавливается политика для корневой файловой системы:

# setfsmac -ef /etc/policy.contexts /

Далее добавьте эти изменения в основной раздел файла /etc/mac.conf:

default_labels file ?biba
default_labels ifnet ?biba
default_labels process ?biba
default_labels socket ?biba

18.7.4. Конфигурация загрузчика

Для завершения настройки добавьте следующие строки в /boot/loader.conf:

mac_biba_load="YES"
mac_seeotheruids_load="YES"
security.mac.biba.trust_all_interfaces=1

Добавьте следующую строку в конфигурацию сетевой карты, хранящуюся в /etc/rc.conf. Если основная настройка сети выполняется через DHCP, это может потребовать ручной настройки после каждой загрузки системы:

maclabel biba/equal

18.7.5. Проверка конфигурации

Сначала убедитесь, что веб-сервер и Nagios не будут запускаться при инициализации системы и перезагрузке. Убедитесь, что root не имеет доступа к любым файлам в конфигурационном каталоге Nagios. Если root может просматривать содержимое /var/spool/nagios, значит что-то не так. Вместо этого должна возвращаться ошибка "permission denied".

Если все выглядит нормально, можно запустить Nagios, Apache и Sendmail:

# cd /etc/mail && make stop && \
setpmac biba/equal make start && setpmac biba/10\(10-10\) apachectl start && \
setpmac biba/10\(10-10\) /usr/local/etc/rc.d/nagios.sh forcestart

Тщательно проверьте, чтобы всё работало правильно. Если нет, проверьте файлы журналов на наличие сообщений об ошибках. При необходимости используйте sysctl(8) для отключения модуля политики безопасности mac_biba(4) и попробуйте запустить всё снова как обычно.

Пользователь root всё ещё может изменять параметры безопасности и редактировать конфигурационные файлы. Следующая команда разрешит понижение уровня целостности политики безопасности для нового запущенного shell:

# setpmac biba/10 csh

Чтобы предотвратить это, принудительно ограничьте пользователя диапазоном с помощью login.conf(5). Если setpmac(8) попытается выполнить команду вне пределов компартмента, будет возвращена ошибка и команда не выполнится. В данном случае установите root в biba/high(high-high).

18.8. Устранение проблем с инфраструктурой MAC

Этот раздел посвящён распространённым ошибкам конфигурации и способам их устранения.

Флаг multilabel не сохраняется на корневом (/) разделе: Следующие действия могут помочь устранить эту временную ошибку:

Отредактируйте файл /etc/fstab и установите корневой раздел в ro для режима только для чтения.
Перезагрузитесь в однопользовательском режиме.
Выполните команду tunefs -l enable для раздела /.
Перезагрузите систему.
Выполните mount -urw/, измените ro обратно на rw в /etc/fstab и перезагрузите систему снова.
Перепроверьте вывод команды mount, чтобы убедиться, что опция multilabel корректно установлена для корневой файловой системы.

После настройки безопасной среды с MAC, Xorg больше не запускается: Это может быть вызвано политикой MAC partition или ошибкой маркировки в одной из политик маркировки MAC. Для диагностики попробуйте следующее:

Проверьте сообщение об ошибке. Если пользователь находится в классе insecure, проблема может быть в политике partition. Попробуйте вернуть пользователя в класс default и пересобрать базу данных с помощью cap_mkdb. Если это не решит проблему, перейдите ко второму шагу.
Перепроверьте, что политики меток правильно установлены для пользователя, Xorg и записей в /dev.
Если ни один из этих способов не решит проблему, отправьте сообщение об ошибке и описание окружения на Список рассылки, посвящённый вопросам и ответам пользователей FreeBSD.

Появляется ошибка _secure_path: unable to stat .login_conf: Этот ошибка может возникать, когда пользователь пытается переключиться с пользователя root на другого пользователя в системе. Это сообщение обычно появляется, когда у пользователя установлена более высокая метка, чем у пользователя, в которого он пытается переключиться. Например, если у joe метка по умолчанию biba/low, а у root — biba/high, root не сможет просмотреть домашний каталог joe. Это произойдет независимо от того, использовал ли root команду su для переключения на joe, так как модель целостности Biba не позволяет root просматривать объекты с более низким уровнем целостности.
Система больше не распознает root: Когда это происходит, whoami возвращает 0, а su выводит who are you?.
Это может произойти, если политика меток была отключена через sysctl(8) или модуль политики был выгружен. Если политика отключена, необходимо перенастроить базу данных возможностей входа. Проверьте файл /etc/login.conf, чтобы убедиться, что все опции label удалены, и перестройте базу данных с помощью cap_mkdb.
Это также может произойти, если политика ограничивает доступ к master.passwd. Обычно это происходит, когда администратор изменяет файл под меткой, которая конфликтует с общей политикой, используемой системой. В таких случаях система прочитает информацию о пользователе, но доступ будет заблокирован, так как файл унаследовал новую метку. Отключите политику с помощью sysctl(8), и всё должно вернуться в норму.

Изменено: 24 ноября 2025 г. by Vladlen Popolitov

Главная