Метка MAC это атрибут безопасности, который может
быть применен к субъектам и объектам всей системы.
При установке метки пользователь должен в точности понимать, что именно она делает.
Атрибуты, доступные для объекта, зависят от загруженной политики, а политики
интерпретируют свои атрибуты совершенно различным образом. Результатом недостаточного
понимания настроек может стать их неправильная реализация, что может привести к
неожиданному, и возможно нежелательному поведению системы.
Метка безопасности на объекте используется политикой для определения правил доступа.
Для некоторых политик метка сама по себе содержит всю необходимую для этого информацию, в
других моделях метки могут обрабатываться как часть большого набора правил, и т.д.
Например, установка метки в biba/low на файле присвоит
этому файлу метку, обрабатываемую политикой Biba со значением ``low''.
Несколько политик, поддерживающих метки в FreeBSD, предоставляют три определенные
предустановленные метки. Это низкая, высокая и равная метки. Хотя они устанавливают
контроль различными способами для каждой политики, вы можете быть уверены, что низкая
метка задаст минимальные установки, равная метка означает отмену или недействительность,
а высокая метка установит максимально возможные настройки в политиках Biba и MLS.
При применении в файловой системе одиночной метки, только одна метка может быть
использована для объектов. Это вызовет установку одних и тех же прав доступа для всей
системы, и во многих случаях это все, что необходимо. Тем не менее, существует несколько
ситуаций, в которых на объекты и субъекты файловой системы могут быть установлены
множественные метки. В этих ситуациях необходимо с помощью tunefs(8) установить
параметр multilabel.
В случае Biba и MLS может быть установлена числовая
метка для указания точного уровня иерархического контроля. Этот числовой уровень
используется для разделения или сортировки информации по различным группам классификации,
разрешающей доступ только к этой группе или группе с более высоким уровнем.
В большинстве случаев системный администратор использует только одну метку на всю
файловую систему.
Постойте, но это же похоже на DAC! Я думал, что MAC дает
контроль только администратору. Это утверждение все еще верно, только root контролирует и настраивает политики, так что пользователи
помещаются в соответствующие категории/уровни доступа. Многие политики могут ограничить
также и пользователя root. Базовый контроль над объектами затем
передается группе, но пользователь root может отменить или
изменить эти настройки в любое время. Данная иерархическая модель соответствует таким
политикам как Biba и MLS.
Практически все действия по настройке политики с метками могут быть выполнены с
использованием утилит базовой системы. Эти команды обеспечивают простой интерфейс для
настройки объектов или субъектов, или для изменения и проверки настроек.
Все настройки могут быть выполнены с использованием утилит setfmac(8) и setpmac(8). Команда
setfmac используется для установки меток MAC на системные объекты, а команда setpmac используется для установки меток на системные субъекты.
Выполните:
# setfmac biba/high test
Если не произойдет ошибок, будет возвращено приглашение командной строки, как и после
команд chmod(1) и chown(8). В некоторых
случаях может появиться ошибка ``Permission denied'', и она
обычно появляется при установке или изменении метки на объект с ограничениями.
Системный администратор для обхода этой проблемы может использовать следующие
команды:
# 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''.
Пользователям необходимо иметь метки, чтобы их файлы и процессы могли правильно
взаимодействовать с определенной в системе политикой безопасности. Это настраивается
через файл login.conf путем использования классов. Каждая
политика, использующая метки, реализует установку класса пользователя.
Пример записи, содержащей все политики, приведенные ниже:
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),lomac10[2]:
Параметр label используется для установки метки MAC по умолчанию для класса пользователя. Пользователи не
смогут изменять это значение, поэтому его можно признать не опциональным. В реальной
ситуации администратору никогда не потребуется включать каждую политику. Рекомендуется
прочесть главу полностью перед реализацией любой из этих настроек.
Замечание: Пользователи могут изменить свою метку после входа; однако политика
накладывает ограничение на это изменение. В примере выше политике Biba указано, что
минимальная целостность процесса 5, максимальная 15, а эффективная целостность по
умолчанию 10. Процесс будет работать на уровне 10, пока метка не будет изменена, например
если пользователь использует команду setpmac, которую Biba ограничит диапазоном,
установленным при входе.
Во всех случаях после изменения login.conf, база данных
``login class capability'' должна быть пересобрана с использованием команды cap_mkdb и это будет отражено в каждом последующем примере
главы.
Полезно отметить, что количество пользователей, которым требуются различные классы, во
многих сетях может быть велико. Необходимо тщательное планирование, поскольку управление
такой сетью может серьезно усложниться.
В будущих версиях FreeBSD появится новый способ связывания пользователей с метками;
однако, он будет доступен только через некоторое время после выхода FreeBSD 5.3.
Метки также могут быть установлены на сетевые интерфейсы, для контроля потока данных в
сети. Во всех случаях они функционируют аналогично тому, как политики по отношению к
объектам. Пользователи с высокими установками, например, biba,
не смогут получить доступ к сетевым интерфейсам с низкими установками.
Для установки MAC меток на сетевых интерфейсах
параметр maclabel может быть передан ifconfig. Например:
# ifconfig bge0 maclabel biba/equal
установит MAC метку biba/equal на интерфейс 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 на файловых
системах. Это может быть сделано только в однопользовательском режиме:
# tunefs -l enable /
Это не требуется для файловой системы подкачки.
Замечание: Некоторые пользователи сталкиваются с проблемами при установке флага
multilabel на корневой раздел. В данном случае обратитесь к Разд. 15.16.
Независимо от загрузки модулей, существует несколько частей MAC, которые могут быть настроены с использованием интерфейса
sysctl. Эти переменные описаны ниже и во всех случаях значение 1
означает включение, а 0 -- отключение:
-
security.mac.enforce_fs по умолчанию установлена в 1 и
включает политики MAC на файловых системах.
-
security.mac.enforce_kld по умолчанию 1 и включает
линкование политик MAC в ядре (см. 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 на сокетах (см. страницу справочника socket(2)).
-
security.mac.enforce_system по умолчанию 1 и включает
политики MAC для действий системы, таких как учет
(accounting) и перезагрузка.
-
security.mac.enforce_vm по умолчанию 1 и включает политики
MAC для системы виртуальной памяти.
Замечание: Каждая политика MAC поддерживает
переменные sysctl. Они обычно попадают в дерево security.mac.<policyname>. Для просмотра всех переменных
MAC, используйте следующую команду:
# sysctl -da | grep mac
Это должно быть интерпретировано так, что все основные политики MAC включены по умолчанию. Если модули встроены в ядро, система
будет заблокирована, и скорее всего не сможет связаться с локальной сетью или с интернет,
и т.д. Поэтому встраивание модулей в ядро не рекомендуется. Не потому, что это ограничит
возможность отключения командой sysctl, а потому, что включение
политик в виде модулей позволит администратору переключать политики системы без
необходимости пересборки и переустановки новой системы.