---
title: Глава 15. Принудительный контроль доступа (MAC)
part: Часть III. Системное администрирование
prev: books/handbook/security
next: books/handbook/audit
showBookMenu: true
weight: 19
params:
  path: "/books/handbook/mac/"
---

[[mac]]
= Принудительный контроль доступа (MAC)
:doctype: book
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:sectnumoffset: 15
:partnums:
:source-highlighter: rouge
:experimental:
:images-path: books/handbook/mac/

ifdef::env-beastie[]
ifdef::backend-html5[]
:imagesdir: ../../../../images/{images-path}
endif::[]
ifndef::book[]
include::shared/authors.adoc[]
include::shared/mirrors.adoc[]
include::shared/releases.adoc[]
include::shared/attributes/attributes-{{% lang %}}.adoc[]
include::shared/{{% lang %}}/teams.adoc[]
include::shared/{{% lang %}}/mailing-lists.adoc[]
include::shared/{{% lang %}}/urls.adoc[]
toc::[]
endif::[]
ifdef::backend-pdf,backend-epub3[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]
endif::[]

ifndef::env-beastie[]
toc::[]
include::../../../../../shared/asciidoctor.adoc[]
endif::[]

[[mac-synopsis]]
== Краткий обзор

FreeBSD 5.X представляет новые расширения системы безопасности от проекта TrustedBSD, основанные на документах POSIX(R).1e. Два из наиболее важных нововведений в механизмах безопасности это списки контроля доступа файловой системы (Access Control Lists, ACLs) и принудительный контроль доступа Mandatory Access Control, MAC). Инфраструктура позволяет загружать новые модули контроля доступа, реализуя новые политики безопасности. Некоторые из них предоставляют защиту ключевых подсистем, защищая определенный сервис, в то время как другие предоставляют исчерпывающую систему безопасности с метками на всех субъектах и объектах. Контроль называется принудительным, поскольку применение контроля производится администраторами и системой, и не зависит от решения пользователей, как это происходит при обычном контроле доступа (Discretionary Access Control, DAC, стандартные файловые и System V IPC права в FreeBSD).

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

После прочтения этой главы вы узнаете:

* Какие модули MAC включены в настоящее время в FreeBSD, какие политики с ними связаны.
* Что способны реализовать политики MAC, различие между политиками с метками (label) и без меток.
* Как эффективно настроить систему для использования инфраструктуры MAC.
* Как настроить различные политики, используемые модулями MAC.
* Как реализовать более защищенную среду, используя инфраструктуру MAC и приведенные примеры.
* Как протестировать настройку MAC, чтобы убедиться, что инфраструктура была реализована правильно.

Перед прочтением этой главы вам потребуется:

* Понимание основ UNIX(R) и FreeBSD (crossref:basics[basics, Основы UNIX]).
* Ознакомиться с основами настройки/компилирования ядра (crossref:kernelconfig[kernelconfig, Настройка ядра FreeBSD]).
* Иметь некоторые понятия о безопасности и как она относится к FreeBSD (crossref:security[security, Безопасность]).

[WARNING]
====

Неправильное использование информации этой главы может вызвать потерю доступа к системе, проблемы у пользователей, или невозможность запуска XFree86(TM). Что более важно, MAC не должен восприниматься как полная защита системы. Инфраструктура MAC лишь усиливает имеющуюся систему безопасности: без применения методов защиты и регулярных проверок, система никогда не станет полностью защищенной.

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

=== Что не будет затронуто

В этой главе охвачен широкий спектр вопросов безопасности, относящихся к инфраструктуре MAC. однако разработка политик MAC не будет затронута. Несколько модулей, включенных в инфраструктуру MAC, имеют особые характеристики, которые предназначены для тестирования и разработки новых модулей. Это относится к модулям/политикам man:mac_test[4], man:mac_stub[4] и man:mac_none[4]. За дальнейшей информацией по этим модулям и различным предоставляемым ими механизмам, обратитесь к соответствующим страницам справочника.

[[mac-inline-glossary]]
== Ключевые термины этой главы

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

* _отдел_ (compartment): Отдел это набор программ и данных, которые необходимо отделить, и где пользователи получают явный доступ к отдельным компонентам системы. Отдел представляет группирование, например рабочую группу, департамент, проект или тему. С использованием отделов возможна реализация политики с явно определенным доступом.
* _целостность_ (integrity): Целостность, как ключевая концепция, это уровень доверия, который может быть присвоен данным. Поскольку целостность данных повышается, это дает возможность доверять данным.
* _метка_ (label): Метка является инструментом безопасности, она может быть применена к файлам, каталогам и другим сущностям системы. Ее можно представить как штамп конфиденциальности; метка, помещенная на файл, описывает уровень секретности данного файла и разрешит доступ только файлам, пользователям, ресурсам и т.д. с теми же или меньшими установками безопасности. Некоторые из политик могут обрабатывать метки различными способами; это будет обсуждаться в разделе политик ниже.
* _multilabel_ (множественные метки): свойство `multilabel` это параметр файловой системы, который может быть установлен в однопользовательском режиме с помощью утилиты man:tunefs[8], во время загрузки через файл man:fstab[5], или при создании новой файловой системы. Этот параметр позволяет администратору помещать различные метки MAC на различные объекты. разрешает помещение множественных MAC меток на файлы и каталоги файловой системы. Этот параметр применим только к политикам с метками.
* _объект_ (object): Объект или системный объект это сущность, через которую информация проходит к _субъекту_. Это могут быть каталоги, файлы, поля, экраны, клавиатуры, память, магнитные накопители, принтеры или любые другие устройства хранения/перемещения данных. В сущности это контейнер данных или ресурс системы; доступ к _объекту_ фактически означает доступ к данным.
* _политика_ (policy): Набор правил, определяющих как достичь объекта. _Политика_ обычно документирует обращение с определенными элементами. В этой главе _политика_ будет означать _политику безопасности_; т.е. коллекцию правил, которые будут контролировать поток данных и определять кто будет иметь доступ к этим данным.
+
* _чувствительность_ (sensitivity): Обычно используется при обсуждении MLS. Уровень чувствительности это термин, используемый для описания того, насколько важны или секретны данные. Увеличение уровня чувствительности означает важность данных.
* _одиночная метка_ (single label): означает, что вся файловая система использует одну метку для определения доступа всего потока данных. Когда файловая система использует эту установку, что происходит всегда, если не установлен параметр `multilabel`, ко всем файлам будет применяться одна и та же установка метки.
* _субъект_ (subject): субъект это любая активная сущность, вызывающая перемещение информации между _объектами_; т.е. пользователь, пользовательский обработчик, системный процесс и т.д. В FreeBSD это почти всегда поток, работающий в процессе или представляющий пользователя.

[[mac-initial]]
== Описание MAC

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

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

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

Право выбора правильных политик безопасности принадлежит только системному администратору. В некоторых случаях может потребоваться ограничение доступа через сеть; для этого могут пригодиться man:mac_portacl[4], man:mac_ifoff[4] и даже man:mac_biba[4]. В других случаях может быть необходима строгая конфиденциальность объектов в файловой системе. Для этого существуют политики man:mac_bsdextended[4] и man:mac_mls[4].

Выбор политики может быть сделан на основе конфигурации сети. Возможно только определенным пользователям можно разрешить доступ через man:ssh[1] к сети или интернет. В таких ситуациях подойдет политика man:mac_portacl[4]. Но что необходимо сделать для файловых систем? Должен ли доступ к определенным каталогам быть запрещен для других групп или определенных пользователей? Или мы должны ограничить доступ пользователей или утилит к определенным файлам путем классификации определенных объектов?

В случае файловой системы, доступ может считаться конфиденциальным для отдельных пользователей, но не для всех. Например, большая команда разработчиков может быть разбита на небольшие группы. Разработчикам проекта A может быть не разрешен доступ к объектам, написанным разработчиками из проекта B. Хотя им может понадобиться доступ к объектам, созданным разработчиками проекта C; это реально встречающаяся ситуация. С помощью различных политик, предоставляемых инфраструктурой MAC, пользователи могут быть разделены на эти три группы и затем получить доступ к соответствующим областям без опасности утечки информации.

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

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

[.programlisting]
....
options	MAC
....

Затем необходимо пересобрать и переустановить ядро.

[CAUTION]
====

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

[[mac-understandlabel]]
== Метки MAC

Метка MAC это атрибут безопасности, который может быть применен к субъектам и объектам всей системы.

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

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

Например, установка метки в `biba/low` на файле присвоит этому файлу метку, обрабатываемую политикой Biba со значением "low".

Несколько политик, поддерживающих метки в FreeBSD, предоставляют три определенные предустановленные метки. Это низкая, высокая и равная метки. Хотя они устанавливают контроль различными способами для каждой политики, вы можете быть уверены, что низкая метка задаст минимальные установки, равная метка означает отмену или недействительность, а высокая метка установит максимально возможные настройки в политиках Biba и MLS.

При применении в файловой системе одиночной метки, только одна метка может быть использована для объектов. Это вызовет установку одних и тех же прав доступа для всей системы, и во многих случаях это все, что необходимо. Тем не менее, существует несколько ситуаций, в которых на объекты и субъекты файловой системы могут быть установлены множественные метки. В этих ситуациях необходимо с помощью man:tunefs[8] установить параметр `multilabel`.

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

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

_Постойте, но это же похоже на DAC! Я думал, что MAC дает контроль только администратору._ Это утверждение все еще верно, только `root` контролирует и настраивает политики, так что пользователи помещаются в соответствующие категории/уровни доступа. Многие политики могут ограничить также и пользователя `root`. Базовый контроль над объектами затем передается группе, но пользователь `root` может отменить или изменить эти настройки в любое время. Данная иерархическая  модель соответствует таким политикам как Biba и MLS.

=== Настройка меток

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

Все настройки могут быть выполнены с использованием утилит man:setfmac[8] и man:setpmac[8]. Команда `setfmac` используется для установки меток MAC на системные объекты, а команда `setpmac` используется для установки меток на системные субъекты. Выполните:

[source,shell]
....
# setfmac biba/high test
....

Если не произойдет ошибок, будет возвращено приглашение командной строки, как и после команд man:chmod[1] и man:chown[8]. В некоторых случаях может появиться ошибка `Permission denied`, и она обычно появляется при установке или изменении метки на объект с ограничениями.  Системный администратор для обхода этой проблемы может использовать следующие команды:

[source,shell]
....
# setfmac biba/high test
Permission denied
# setpmac biba/low setfmac biba/high test
# getfmac test
test: biba/high
....

Как видно из примера выше, команда `setpmac` может быть использована для изменения установок политики путем присвоения иной метки вызывающему процессу. Утилита `getpmac` обычно используется с существующим на данный момент процессом, таким как sendmail, хотя она принимает PID вместо команды, ее действие аналогично. Если пользователи попытаются манипулировать файлами, к которым у них нет доступа в соответствии с правилами загруженных политик, функцией `mac_set_link` будет выдано сообщение об ошибке `Operation not permitted`.

==== Пользователи и установки меток

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

Пример записи, содержащей все политики, приведенные ниже:

[.programlisting]
....
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/shared/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),lomac10[2]:
....

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

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

Во всех случаях после изменения [.filename]#login.conf#, база данных "login class capability" должна быть пересобрана с использованием команды `cap_mkdb` и это будет отражено в каждом последующем примере главы.

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

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

==== Сетевые интерфейсы и установка меток

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

Для установки MAC меток на сетевых интерфейсах параметр `maclabel` может быть передан `ifconfig`. Например:

[source,shell]
....
# ifconfig bge0 maclabel biba/equal
....

установит MAC метку `biba/equal` на интерфейс man:bge[4]. При использовании метки, подобной `biba/high(low-high)` вся метка должна быть взята в кавычки, иначе будет выдано сообщение об ошибке.

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

=== Одиночные или множественные метки?

По умолчанию система будет использовать параметр `singlelabel`. Но что это означает для администратора? Существуют несколько различий между политиками, каждая из которых правильна сама по себе, но имеет свои доводы за и против относительно гибкости модели безопасности системы.

`singlelabel` (одиночная метка) разрешает использование только одной метки, например `biba/high`, для каждого объекта или субъекта. Ее преимущество в меньшей нагрузке на системного администратора, а недостаток в малой гибкости политик, поддерживающих метки. Многие администраторы в своих политиках безопасности могут предпочесть использование параметра `multilabel`.

С параметром `multilabel` каждый субъект или объект может иметь собственную метку MAC, в то время как со стандартным параметром `singlelabel` возможна только одна метка на весь раздел. Параметры `multilabel` и `singlelabel` требуются только для политик, реализующих метки, включая Biba, Lomac, MLS и SEBSD.

Во многих случаях `multilabel` может вообще не потребоваться. Предположим следующую ситуацию и модель безопасности:

* FreeBSD веб-сервер, использующий инфраструктуру MAC и набор различных политик.
* Этому компьютеру потребуется лишь одна метка, `biba/high`, для всей системы. Файловой системе не нужен параметр `multilabel`, поскольку по умолчанию работает одиночная метка.
* Но поскольку этот компьютер будет веб сервером, процесс веб сервера должен быть запущен с `biba/low` для предотвращения записи. Политика Biba и то, как она работает, будет обсуждаться позже, поэтому предыдущий комментарий сложно интерпретировать; просто продолжайте чтение. Сервер может использовать дисковый раздел с установленной меткой `biba/low` для большинства, если не для всех своих операций. В этом примере отсутствуют многие детали, такие как ограничения на данные, конфигурация системы и установки пользователей; однако, это лишь предварительный пример.

Если используется любая из политик, не поддерживающих метки, параметр `multilabel` не требуется. Сюда включаются политики `seeotheruids`, `portacl` и `partition`.

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

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

[source,shell]
....
# tunefs -l enable /
....

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

[NOTE]
====
Некоторые пользователи сталкиваются с проблемами при установке флага `multilabel` на корневой раздел. В данном случае обратитесь к <<mac-troubleshoot>>.
====

=== Настройка MAC переменными sysctl

Независимо от загрузки модулей, существует несколько частей MAC, которые могут быть настроены с использованием интерфейса `sysctl`. Эти переменные описаны ниже и во всех случаях значение 1 означает включение, а 0 - отключение:

* `security.mac.enforce_fs` по умолчанию установлена в 1 и включает политики MAC на файловых системах.
* `security.mac.enforce_kld` по умолчанию 1 и включает линкование политик MAC в ядре (см. man:kld[4]).
* `security.mac.enforce_network` по умолчанию 1 и включает сетевые политики MAC.
* `security.mac.enforce_pipe` по умолчанию 1 и включает политики MAC для каналов (pipe).
* `security.mac.enforce_process` по умолчанию 1 и включает политики MAC для процессов, использующих средства межпроцессного взаимодействия.
* `security.mac.enforce_socket` по умолчанию 1 и включает политики MAC на сокетах (см. страницу справочника man:socket[2]).
* `security.mac.enforce_system` по умолчанию 1 и включает политики MAC для действий системы, таких как учет (accounting) и перезагрузка.
* `security.mac.enforce_vm` по умолчанию 1 и включает политики MAC для системы виртуальной памяти.

[NOTE]
====
Каждая политика MAC поддерживает переменные `sysctl`. Они обычно попадают в дерево `security.mac.<policyname>`. Для просмотра всех переменных MAC, используйте следующую команду:

[source,shell]
....
# sysctl -da | grep mac
....

====

Это должно быть интерпретировано так, что все основные политики MAC включены по умолчанию. Если модули встроены в ядро, система будет заблокирована, и скорее всего не сможет связаться с локальной сетью или с интернет, и т.д. Поэтому встраивание модулей в ядро не рекомендуется. Не потому, что это ограничит возможность отключения командой `sysctl`, а потому, что включение политик в виде модулей позволит администратору переключать политики системы без необходимости пересборки и переустановки новой системы.

[[mac-modules]]
== Настройка модулей

Каждый модуль, включенный в инфраструктуру MAC, может быть или встроен в ядро, как упоминалось выше, или загружен в виде модуля ядра. Рекомендуется добавление имени модуля в файл [.filename]#/boot/loader.conf#, этот модуль будет активирован в самом начале загрузки.

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

Конфигурация с одной меткой не допускает применение нескольких меток в системе, поэтому параметр `tunefs` называется `multilabel`.

[[mac-seeotheruids]]
=== Модуль MAC seeotheruids

Имя модуля: [.filename]#mac_seeotheruids.ko#

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

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

Модуль man:mac_seeotheruids[4] копирует и расширяет переменные `sysctl security.bsd.see_other_uids` и `security.bsd.see_other_gids`. Он не требует установки меток и может прозрачно работать с другими модулями.

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

* `security.mac.seeotheruids.enabled` включит модуль с настройками по умолчанию. Эти настройки запрещают пользователям просмотр процессов и сокетов, принадлежащих другим пользователям.
* `security.mac.seeotheruids.specificgid_enabled` позволит исключить определенные группы из этой политики. Для исключения определенной группы, используйте переменную `sysctl security.mac.seeotheruids.specificgid=_XXX_`. В примере выше необходимо заменить _XXX_ на числовой ID группы.
* `security.mac.seeotheruids.primarygroup_enabled` используется для исключения определенной основной группы из этой политики. При использовании этой переменной `security.mac.seeotheruids.specificgid_enabled` может быть не установлена.

Необходимо отметить, что пользователь `root` не является исключением из этой политики. Это одно из самых существенных различий между MAC версией и обычными переменными, существующими по умолчанию: `security.bsd.seeotheruids`.

[[mac-bsdextended]]
== Модуль MAC bsdextended

Имя модуля: [.filename]#mac_bsdextended.ko#

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

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

Модуль man:mac_bsdextended[4] включает брандмауэр файловой системы. Политика этого модуля является расширением стандартной модели разрешений файловой системы, позволяя администратору создавать набор правил для защиты файлов, утилит и каталогов иерархии файловой системы в стиле брандмауэра.

Политика может быть создана с помощью утилиты, man:ugidfw[8], синтаксис которой похож на синтаксис man:ipfw[8]. Другие инструменты могут быть написаны с использованием функций библиотеки man:libugidfw[3].

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

=== Примеры

После загрузки модуля man:mac_bsdextended[4] для просмотра текущей настройки правил может быть использована следующая команда:

[source,shell]
....
# ugidfw list
0 slots, 0 rules
....

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

[source,shell]
....
# ugidfw add subject not uid root new object not uid root mode n
....

[NOTE]
====
В релизах FreeBSD до 5.3, параметр [parameter]#add# не существует. Вместо него необходимо использовать [parameter]#set#. Пример дан ниже.
====

Это очень плохая идея, поскольку такое правило запретит пользователям использовать даже самые простые команды, такие как `ls`. Более патриотический список правил может быть таким:

[source,shell]
....
# ugidfw set 2 subject uid user1 object uid user2 mode n
# ugidfw set 3 subject uid user1 object gid user2 mode n
....

Эти команды запретят весь и любой доступ пользователя `user1`, включая просмотр подкаталогов, к домашнему каталогу пользователя `_user2_`.

Вместо `user1` может быть задано `not uid _user2_`. Это включит те ограничения, о которых говорилось выше, для всех пользователей кроме одного.

[NOTE]
====
На пользователя `root` эти изменения не повлияют.
====

Материал выше должен дать общую идею как модуль man:mac_bsdextended[4] может быть использован в качестве средства защиты файловой системы. За дальнейшей информацией обращайтесь к страницам справочника man:mac_bsdextended[4] и man:ugidfw[8].

[[mac-ifoff]]
== Модуль MAC ifoff

Имя модуля: [.filename]#mac_ifoff.ko#

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

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

Модуль man:mac_ifoff[4] существует только для отключения сетевых интерфейсов в работающей системе и удержания их от отправки пакетов во время начальной загрузки. Это не требует установления в системе каких-либо меток, нет и зависимости от других модулей MAC.

Большая часть управления может быть выполнена через переменные `sysctl`.

* `security.mac.ifoff.lo_enabled` включает/выключает весь трафик на loopback (man:lo[4]) интерфейсе.
* `security.mac.ifoff.bpfrecv_enabled` включает/выключает весь трафик на интерфейсе Berkeley Packet Filter (man:bpf[4]).
* `security.mac.ifoff.other_enabled` включает/выключает весь трафик на всех других интерфейсах.

Одно из наиболее частых использований man:mac_ifoff[4] это сетевой мониторинг в среде, где сетевой трафик не должен быть разрешен во время загрузки. Другое предлагаемое применение это написание скрипта, использующего package:security/aide[] для автоматического блокирования сетевого трафика, если будут обнаружены новые или измененные файлы в защищаемых каталогах.

[[mac-portacl]]
== Модуль MAC portacl

Имя модуля: [.filename]#mac_portacl.ko#

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

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

Модуль man:mac_portacl[4] используется для ограничения привязки (binding) к локальным портам TCP и UDP, используя различные переменные `sysctl`. По сути man:mac_portacl[4] делает возможной привязку к привилегированным портам, т.е. к портам с номерами меньше 1024 для не-`root` пользователей.

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

* `security.mac.portacl.enabled` включает/отключает политику целиком. 
* `security.mac.portacl.port_high` установит наибольший номер порта, для которого man:mac_portacl[4] включает защиту.
* `security.mac.portacl.suser_exempt`, если установлена в ненулевое значение, исключает пользователя `root` из этой политики.
* `security.mac.portacl.rules` задает действующую политику mac_portacl: см. ниже.

Действующая политика `mac_portacl`, указанная в `security.mac.portacl.rules`, это текстовая строка в форме `rule[,rule,...]` с таким количеством правил, которое требуется. Каждое правило задается в формате: `idtype:id:protocol:port`. Параметр [parameter]#idtype# может принимать значения `uid` или `gid` и используется для интерпретации параметра [parameter]#id#, в качестве id пользователя или группы соответственно. Параметр [parameter]#protocol# используется для определения применимости этого правила к протоколу TCP или UDP, он может принимать значения `tcp` или `udp`. Последний параметр, [parameter]#port#, задает номер порта, к которому разрешается привязка указанного пользователя или группы.

[NOTE]
====
Поскольку набор правил интерпретируется непосредственно ядром, для ID пользователя, группы и номера порта могут быть использованы только числовые значения. Т.е. имена пользователей, групп и сервисов портов не могут быть использованы.
====

По умолчанию в UNIX(R)-подобных системах порты с номерами менее чем 1024 могут быть использованы только привилегированными процессами, т.е. теми, что запущены от `root`. С man:mac_portacl[4] для разрешения привязки непривилегированных процессов к портам с номерами ниже 1024 эти стандартные ограничения UNIX(R) должны быть отменены. Это может быть выполнено путем установки переменных man:sysctl[8] `net.inet.ip.portrange.reservedlow` и `net.inet.ip.portrange.reservedhigh` в ноль.

Обратитесь к примерам ниже или к странице справочника man:mac_portacl[4] за дальнейшей информацией.

=== Примеры

Следующие примеры должны осветить обсуждение выше чуть лучше:

[source,shell]
....
# sysctl security.mac.portacl.port_high=1023
# sysctl net.inet.ip.portrange.reservedlow=0 net.inet.ip.portrange.reservedhigh=0
....

Сначала мы настраиваем man:mac_portacl[4] для работы со стандартными привилегированными портами и отмены обычных ограничений UNIX(R) на привязку.

[source,shell]
....
# sysctl security.mac.portacl.suser_exempt=1
....

Пользователь `root` должен быть исключен из этой политики, для этого переменная `security.mac.portacl.suser_exempt` установлена в ненулевое значение. Модуль man:mac_portacl[4] теперь настроен на то поведение UNIX(R)-подобных систем по умолчанию.

[source,shell]
....
# sysctl security.mac.portacl.rules=uid:80:tcp:80
....

Разрешает пользователю с UID 80 (обычно это пользователь `www`) привязку к порту 80. Теперь пользователь `www` сможет запустить веб сервер даже без привилегии `root`.

[source,shell]
....
# sysctl security.mac.portacl.rules=uid:1001:tcp:110,uid:1001:tcp:995
....

Разрешит пользователю с UID 1001 привязку к TCP портам 110 ("pop3") и 995 ("pop3s"). Это позволит данному пользователю запустить сервер, принимающий соединения на портах 110 и 995.

[[mac-labelingpolicies]]
== Политики MAC, использующие метки

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

С этого момента обсуждение будет сфокусировано на возможностях man:mac_biba[4], man:mac_lomac[4], man:mac_partition[4], и man:mac_mls[4].

[NOTE]
====
Это лишь примерные настройки, они не должны использоваться непосредственно в реальных задачах. Цель изложения в том, чтобы документировать и показать синтаксис, а также примеры реализации и тестирования.
====

Для правильной работы этих политик необходимо выполнить некоторые приготовления.

[[mac-prep]]
=== Приготовления к использованию политик с метками

В файл [.filename]#login.conf# необходимо внести следующие изменения:

* Должен быть добавлен класс `insecure`, или другой подобный класс. Наличие класса `insecure` не обязательно, он приводится здесь в качестве примера; другие конфигурации могут использовать другое имя класса.
* Класс `insecure` должен использовать приведенные ниже настройки и определения. Некоторые из них могут быть изменены, но строка, определяющая метку по умолчанию, необходима и должна быть оставлена.
+
[.programlisting]
....
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/shared/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/low:
....

+ 
Перед тем, как переключать пользователей на новый класс, необходимо запустить команду man:cap.mkdb[1] на man:login.conf[5].
+ 
Пользователю `root` также необходимо присвоить класс; иначе, почти любой команде, выполняемой от `root`, потребуется использование `setpmac`.
+
* Убедитесь, что все разделы, на которых будут установлены метки MAC, поддерживают параметр `multilabel`. Нам необходимо сделать это, поскольку многие из примеров здесь содержат различные метки в целях тестирования. Просмотрите вывод команды `mount` в качестве необходимой предосторожности.
* Переключите всех пользователей, которые будут использовать новые механизмы безопасности, на этот класс. Информация по этой процедуре находится в man:pw[8] или man:vipw[8].

[[mac-partition]]
== Модуль MAC partition

Имя модуля: [.filename]#mac_partition.ko#

Строка настройки ядра: `options MAC_PARTITION`

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

Политика man:mac_partition[4] распределяет процессы по "разделам" на основе их MAC меток. Это может быть представлено как особый тип man:jail[8], хотя такое сравнение едва ли подходит.

Этот модуль должен быть добавлен в man:loader.conf[5], чтобы политика была загружена и включена при загрузке системы.

Большая часть настройки этой политики выполняется с помощью утилиты man:setpmac[8], которая будет описана ниже. Для данной политики имеется также следующая переменная `sysctl`:

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

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

Для присвоения утилитам меток partition используйте утилиту `setpmac`:

[source,shell]
....
# setpmac partition/13 top
....

Команда `top` будет добавлена к метке, установленной для пользователей класса `insecure`. Обратите внимание, что все процессы, порожденные пользователями класса `insecure`, останутся с меткой `partition/13`.

=== Примеры

Следующая команда покажет вашу метку раздела и список процессов:

[source,shell]
....
# ps Zax
....

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

[source,shell]
....
# ps -ZU trhodes
....

[NOTE]
====
Пользователи могут могут увидеть процессы `root`, если не загружена политика man:mac_seeotheruids[4].
====

Действительно "продвинутая" реализация должна отключать все сервисы через [.filename]#/etc/rc.conf# и запускать их через скрипт, который установит правильный набор меток.

[NOTE]
====
Следующие политики поддерживают целочисленные установки вместо трех меток по умолчанию. Эти опции, включая их ограничения, описываются более подробно в страницах справочника модулей.
====

[[mac-mls]]
== Модуль многоуровневой безопасности MAC (MLS)

Имя модуля: [.filename]#mac_mls.ko#

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

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

Политика man:mac_mls[4] контролирует взаимодействие субъектов и объектов системы путем применения строгой политики к потоку информации.

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

Эти метки `mls/low`, `mls/equal` и `mls/high`. Поскольку эти метки подробно описываются в справочнике, здесь мы дадим только краткое описание:

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

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

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

Для настройки специальных сервисов и интерфейсов доступны следующие переменные `sysctl`:

* `security.mac.mls.enabled` используется для включения/отключения политики MLS.
* `security.mac.mls.ptys_equal` пометит все устройства man:pty[4] как `mls/equal` во время создания.
* `security.mac.mls.revocation_enabled` используется для запрета доступа к объектам после того, как их метка изменится в меньшую сторону.
* `security.mac.mls.max_compartments` используется для установки максимального количества уровней отделов на объекты; обычно это максимальное количество отделов, разрешенных в системе.

Для управления метками MLS существует команда man:setfmac[8]. Для присвоения метки объекту, выполните следующую команду:

[source,shell]
....
# setfmac mls/5 test
....

Для получения метки MLS файла [.filename]#test#, выполните следующую команду:

[source,shell]
....
# getfmac test
....

Выше представлен краткий обзор возможностей политики MLS. Существует метод, связанный с созданием основного файла политики в каталоге [.filename]#/etc#, где будет определена необходимая для политики MLS информация, которая будет передана команде `setfmac`. Этот метод будет описан после рассмотрения всех политик.

Итоги: объект с низким уровнем доступа не может прочесть данные объекта с высоким уровнем доступа. Базовая политика должна устанавливать `mls/high` на всем, что не должно быть прочитано, даже если туда необходимо записывать. На всем, куда нельзя писать, должна быть установлена метка `mls/low`, даже если это необходимо читать. Наконец, на всем остальном установите `mls/equal`. Все пользователи, помеченные как `insecure`, должны иметь метку `mls/low`.

[[mac-biba]]
== Модуль MAC Biba

Имя модуля: [.filename]#mac_biba.ko#

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

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

Модуль man:mac_biba[4] загружает MAC политику Biba. Эта политика работает в основном так же, как и MLS, за исключением того, что правила потока информации изменены на противоположные. Они предназначены для предотвращения передачи потока секретной информации вверх, в то время как политика MLS предотвращает передачу потока секретной информации вниз; таким образом, большая часть этого раздела применима к обеим политикам.

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

Поддерживаемые метки `biba/low`, `biba/equal`, и `biba/high`; описаны ниже:

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

Biba представляет собой:

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

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

* `security.mac.biba.enabled` может использоваться для включения/выключения политики Biba.
* `security.mac.biba.ptys_equal` может использоваться для отключения политики Biba на устройствах man:pty[4].
* `security.mac.biba.revocation_enabled` включит отмену доступа к объектам, если метка изменена на более высокую, чем у субъекта.

Для выполнения настроек политики Biba на системных объектах, применяются команды `setfmac` и `getfmac`:

[source,shell]
....
# setfmac biba/low test
# getfmac test
test: biba/low
....

Итоги: субъект с низким уровнем целостности не может писать в субъект с высоким уровнем целостности; субъект с высоким уровнем целостности не может читать из субъекта с низким уровнем целостности.

[[mac-lomac]]
== Модуль MAC LOMAC

Имя модуля: [.filename]#mac_lomac.ko#

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

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

В отличие от политики MAC Biba, политика man:mac_lomac[4] разрешает доступ к объектам с более низким уровнем целостности только после уменьшения уровня целостности, чтобы не нарушать каких-либо правил целостности.

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

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

=== Примеры

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

[source,shell]
....
# setfmac /usr/home/trhodes lomac/high[low]
# getfmac /usr/home/trhodes lomac/high[low]
....

Обратите внимание, что вспомогательная градация здесь `low`, эта возможность предоставляется только политикой MAC LOMAC policy.

[[mac-implementing]]
== Реализация защищенной среды с MAC

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

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

=== Создание insecure класса пользователя

Начните процедуру добавлением следующего класса пользователя к файлу [.filename]#/etc/login.conf#:

[.programlisting]
....
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/shared/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:
....

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

[.programlisting]
....
:label=mls/equal,biba/equal,partition/equal:
....

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

[source,shell]
....
# cap_mkdb /etc/login.conf
....

=== Загрузка с необходимыми модулями

Добавьте к [.filename]#/boot/loader.conf# следующие строки, чтобы необходимые модули были загружены при старте системы:

[.programlisting]
....
mac_biba_load="YES"
mac_mls_load="YES"
mac_seeotheruids_load="YES"
mac_partition_load="YES"
....

=== Установка всех пользователей в insecure

Всем учетным записям, кроме `root` или системных пользователей теперь потребуется присвоить класс (login class). При отсутствии класса пользователи не смогут получить доступа к обычным командам, таким как man:vi[1]. Следующий скрипт `sh` сделает все необходимое:

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

После этого изменения необходимо запустить команду `cap_mkdb` на файле [.filename]#/etc/master.passwd#.

=== Завершение настройки

Должен быть создан файл контекста; следующий пример взят из примера политики от Robert Watson, он может быть помещен в [.filename]#/etc/policy.contexts#:

[.programlisting]
....
# This is the default BIBA/MLS policy for this system.

.*                              biba/high,mls/high
/sbin/dhclient                  biba/high(low),mls/high(low)
/dev(/.*)?                      biba/equal,mls/equal
# This is not an exhaustive list of all "privileged" devices.
/dev/mdctl                      biba/high,mls/high
/dev/pci                        biba/high,mls/high
/dev/k?mem                      biba/high,mls/high
/dev/io                         biba/high,mls/high
/dev/agp.*                      biba/high,mls/high
(/var)?/tmp(/.*)?               biba/equal,mls/equal
/tmp/\.X11-unix                 biba/high(equal),mls/high(equal)
/tmp/\.X11-unix/.*              biba/equal,mls/equal
/proc(/.*)?                     biba/equal,mls/equal
/mnt.*                          biba/low,mls/low
(/usr)?/home                    biba/high(low),mls/high(low)
(/usr)?/home/.*                 biba/low,mls/low
/var/mail(/.*)?                 biba/low,mls/low
/var/spool/mqueue(/.*)?         biba/low,mls/low
(/mnt)?/cdrom(/.*)?             biba/high,mls/high
(/usr)?/home/(ftp|samba)(/.*)?  biba/high,mls/high
/var/log/sendmail\.st           biba/low,mls/low
/var/run/utmp                   biba/equal,mls/equal
/var/log/(lastlog|wtmp)         biba/equal,mls/equal
....

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

Он может быть внесен в систему следующими командами:

[source,shell]
....
# setfsmac -ef /etc/policy.contexts /
# setfsmac -ef /etc/policy.contexts /usr
....

[NOTE]
====
Раскладка вышеприведенной файловой системы может быть различной для разных систем.
====

Файл [.filename]#/etc/mac.conf# требует следующих изменений в основном разделе:

[.programlisting]
....
default_labels file ?biba,?mls
default_labels ifnet ?biba,?mls
default_labels process ?biba,?mls,?partition
default_labels socket ?biba,?mls
....

=== Тестирование настройки

Добавьте пользователя с помощью команды `adduser` и поместите его в класс `insecure` для этих тестов.

В примерах ниже тестирование `root` и обычных пользователей будет смешиваться; форма приглашения поможет различить этих пользователей.

==== Основное тестирование меток

[source,shell]
....
% getpmac
biba/15(15-15),mls/15(15-15),partition/15
# setpmac partition/15,mls/equal top
....

[NOTE]
====
Процесс top будет уничтожен перед тем, как мы запустим другой процесс top.
====

==== Тестирование MAC seeotheruids

[source,shell]
....
% ps Zax
biba/15(15-15),mls/15(15-15),partition/15  1096 #C:  S      0:00.03 -su (bash)
biba/15(15-15),mls/15(15-15),partition/15  1101 #C:  R+     0:00.01 ps Zax
....

Просмотр процессов всех других пользователей должен быть запрещен.

==== Тестирование MAC partition

Отключите политику MAC `seeotheruids` для остальных тестов:

[source,shell]
....
# sysctl security.mac.seeotheruids.enabled=0
% ps Zax
LABEL                                                   PID  TT  STAT      TIME COMMAND
  biba/equal(low-high),mls/equal(low-high),partition/15  1122 #C:  S+     0:00.02 top
  biba/15(15-15),mls/15(15-15),partition/15              1096 #C:  S      0:00.05 -su (bash)
  biba/15(15-15),mls/15(15-15),partition/15              1123 #C:  R+     0:00.01 ps Zax
....

Все пользователи должны видеть каждый процесс в своем разделе (partition).

==== Тестирование меток Biba и MLS

[source,shell]
....
# setpmac partition/15,mls/equal,biba/high\(high-high\) top
% ps Zax
LABEL                                                   PID  TT  STAT    TIME   COMMAND
  biba/high(high-high),mls/equal(low-high),partition/15   1251 #C:  S+     0:00.02 top
  biba/15(15-15),mls/15(15-15),partition/15               1096 #C:  S      0:00.06 -su (bash)
  biba/15(15-15),mls/15(15-15),partition/15               1157 #C:  R+     0:00.00 ps Zax
....

Политика Biba позволяет чтение объектов с более высокими метками.

[source,shell]
....
# setpmac partition/15,mls/equal,biba/low top
% ps Zax
LABEL                                       PID  TT  STAT      TIME COMMAND
  biba/15(15-15),mls/15(15-15),partition/15  1096 #C:  S      0:00.07 -su (bash)
  biba/15(15-15),mls/15(15-15),partition/15  1226 #C:  R+     0:00.01 ps Zax
....

Политика Biba не позволяет чтение объектов с более низкими метками; тем не менее, MLS разрешает это.

[source,shell]
....
% ifconfig bge0 | grep maclabel
maclabel biba/low(low-low),mls/low(low-low)
% ping -c 1 192.0.34.166
PING 192.0.34.166 (192.0.34.166): 56 data bytes
ping: sendto: Permission denied
....

Пользователи не могут выполнить ping на `example.com`, или на любой домен по этой причине.

Для устранения этой ошибки, запустите следующую команду:

[source,shell]
....
# sysctl security.mac.biba.trust_all_interfaces=1
....

Она устанавливает метку интерфейса по умолчанию в незащищенный режим, так что политика Biba по умолчанию не будет применена.

[source,shell]
....
# ifconfig bge0 maclabel biba/equal\(low-high\),mls/equal\(low-high\)
% ping -c 1 192.0.34.166
PING 192.0.34.166 (192.0.34.166): 56 data bytes
64 bytes from 192.0.34.166: icmp_seq=0 ttl=50 time=204.455 ms
--- 192.0.34.166 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 204.455/204.455/204.455/0.000 ms
....

Установив более корректную метку, мы можем использовать `ping`.

Теперь создадим файлы для процедуры тестирования чтения и записи:

[source,shell]
....
# touch test1 test2 test3 test4 test5
# getfmac test1
test1: biba/equal,mls/equal
# setfmac biba/low test1 test2; setfmac biba/high test4 test5; \
  setfmac mls/low test1 test3; setfmac mls/high test2 test4
# setfmac mls/equal,biba/equal test3 && getfmac test?
test1: biba/low,mls/low
test2: biba/low,mls/high
test3: biba/equal,mls/equal
test4: biba/high,mls/high
test5: biba/high,mls/equal
# chown testuser:testuser test?
....

Все эти файлы должны принадлежать пользователю `testuser`. Тесты на чтение:

[source,shell]
....
% ls
test1   test2   test3   test4   test5
% ls test?
ls: test1: Permission denied
ls: test2: Permission denied
ls: test4: Permission denied
test3   test5
....

Доступ на чтение не должен быть разрешен для пар: `(biba/low,mls/low)`, `(biba/low,mls/high)` и `(biba/high,mls/high)`. Теперь несколько тестов на запись:

[source,shell]
....
% for i in `echo test*`; do echo 1 > $i; done
-su: test1: Permission denied
-su: test4: Permission denied
-su: test5: Permission denied
....

Подобно тестам на чтение, доступ на запись должен быть запрещен для пар: `(biba/low,mls/high)` и `(biba/equal,mls/equal)`.

[source,shell]
....
% cat test?
cat: test1: Permission denied
cat: test2: Permission denied
1
cat: test4: Permission denied
....

А теперь от `root`:

[source,shell]
....
# cat test2
1
....

[[MAC-examplehttpd]]
== Другой пример: Использование MAC для защиты веб сервера

Будет создано отдельное хранилище для веб данных, к которому пользователи должны иметь доступ. Это позволит `biba/high` управлять доступом к веб данным.

Начните с создания каталога для хранения веб данных:

[source,shell]
....
# mkdir /usr/home/cvs
....

Теперь инициализируйте его командой `cvs`:

[source,shell]
....
# cvs -d /usr/home/cvs init
....

Для начала необходимо включить политику `biba`, добавив `mac_biba_enable="YES"` в [.filename]#/boot/loader.conf#. Предполагается, что ядро скомпилировано с поддержкой MAC.

Далее установите метку `biba/high` для всей системы по умолчанию.

В файл [.filename]#login.conf#, класс default, необходимо внести следующие изменения:

[.programlisting]
....
:ignoretime@:\
	:umask=022:\
	:label=biba/high:
....

Каждого пользователя необходимо поместить в класс по умолчанию; такая команда:

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

быстро решит эту задачу.

Теперь создадим другой класс, web, копию класса default с меткой, установленной в `biba/low`.

Создайте пользователя для работы с основными веб данными, хранящимися в репозитории cvs. Этого пользователя необходимо поместить в новый класс, `web`.

Поскольку метка по умолчанию `biba/high`, на репозитории она будет той же. Веб данные должны иметь ту же метку, чтобы у пользователей был доступ к ним на чтение/запись. Веб сервер должен иметь доступ к тем же данным, к которым есть доступ у пользователей с меткой `biba/high`, для этого необходимо понизить метку данных.

Все, что потребуется, это следующий man:sh[1] скрипт, который может быть запущен из man:cron[8]:

[.programlisting]
....
PATH=/bin:/usr/bin:/usr/local/bin; export PATH;
CVSROOT=/home/repo; export CVSROOT;
cd /home/web;
cvs -qR checkout -P htdocs;
exit;
....

[NOTE]
====
Во многих случаях в веб файлы `cvs` необходимо поместить теги Id.
====

Этот скрипт теперь может быть помещен в домашний каталог каталог пользователя `web`, необходимо также добавить следующую запись man:crontab[1]:

[.programlisting]
....
# Выполнять checkout web данных под меткой biba/low каждые 12 часов:
0       */12       *       *       *       web    /home/web/checkout.sh
....

Эта запись будет извлекать HTML страницы каждые двенадцать часов.

Метод запуска веб сервера по умолчанию также должен быть изменен для запуска процесса с меткой `biba/low`. Это может быть сделано путем следующего изменения в скрипте [.filename]#/usr/local/etc/rc.d/apache.sh#:

[.programlisting]
....
command="setpmac biba/low /usr/local/sbin/httpd"
....

Настройки Apache должны быть изменены для работы с политикой `biba/low`. В этом случае необходимо указать для хранения лог файлов каталог с меткой `biba/low`, иначе будут возвращены ошибки `access denied`.

[NOTE]
====
В этом примере необходимо указать в директиве `docroot` каталог [.filename]#/home/web/htdocs#; или, Apache не сможет найти каталог с документами.
====

Необходимо также изменить другие параметры конфигурации, включая PID файл, `Scoreboardfile`, `DocumentRoot`, или любые другие настройки для каталогов, где необходим доступ на запись. При использовании `biba` будет запрещен доступ на запись во все каталоги сервера, на которых нет метки `biba/low`.

[[mac-troubleshoot]]
== Решение проблем с инфраструктурой MAC

На стадии разработки несколько пользователей сообщали о проблемах при обычных настройках. Некоторые из этих проблем приведены ниже:

=== Параметр `multilabel` не может быть включен на [.filename]#/#

Параметр `multilabel` не включается на моем корневом ([.filename]#/#) разделе!

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

[.procedure]
====
. Отредактируйте [.filename]#/etc/fstab# и установите для корневого раздела параметр только для чтения (`ro`).
. Перегрузитесь в однопользовательский режим.
. Запустите команду `tunefs -l enable` на [.filename]#/#.
. Перегрузите систему в нормальный режим.
. Запустите `mount -urw`[.filename]#/# и измените параметр `ro` обратно на `rw` в [.filename]#/etc/fstab#; перегрузите систему опять.
. Дважды проверьте вывод `mount`, чтобы убедиться, что параметр `multilabel` был установлен на корневой файловой системе.
====

=== Не могу запустить XFree86(TM) после MAC

После настройки системы безопасности MAC, я больше не могу запускать XFree86(TM)!

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

[.procedure]
====
. Просмотрите сообщение об ошибке; если пользователь находится в классе `insecure`, проблема может быть в политике `partition`. Попробуйте установить класс пользователя обратно в `default` и пересобрать базу данных командой `cap_mkdb`. Если это не решит проблемы, попробуйте шаг два.
. Дважды проверьте политики с метками. Убедитесь, что политики настроены правильно для рассматриваемого пользователя, приложения XFree86(TM), и устройств в [.filename]#/dev#.
. Если проблема не решена, отправьте сообщение об ошибке и описание вашей системы в список рассылки TrustedBSD, находящийся на веб сайте http://www.TrustedBSD.org[TrustedBSD] или в {freebsd-questions}.
====

=== Error: man:_secure_path[3] cannot stat [.filename]#.login_conf#

При попытке переключения от `root` на другого пользователя системы, появляется сообщение об ошибке `_secure_path: unable to state .login_conf`.

Это сообщение обычно показывается, когда у пользователя более высокая метка, чем у пользователя, которым он пытается стать. Например, у пользователя системы `joe` метка по умолчанию `biba/low`. Пользователь `root`, метка которого `biba/high`, не может просматривать домашний каталог пользователя `joe`. Это не зависит от того, использует ли пользователь `root` команду `su joe` или нет. В этом сценарии модель целостности Biba не позволит `root` просматривать объекты с низким уровнем целостности.

=== Пользователя `root` нет!

В нормальном или даже однопользовательском режиме `root` не обнаруживается. Команда `whoami` возвращает 0 (нуль) и `su` возвращает `who are you?`. Что можно сделать?

Это может произойти, если политика с метками была отключена, или через man:sysctl[8], или путем выгрузки модуля политики. Если политика была постоянно или временно отключена, базу данных login необходимо перенастроить. Дважды проверьте [.filename]#login.conf#, чтобы убедиться, что все параметры `label` были удалены и пересоберите базу данных командой `cap_mkdb`.
