Решение проблем с инфраструктурой MAC
На стадии разработки несколько пользователей сообщали о проблемах при обычных настройках. Некоторые из этих проблем приведены ниже:
15.16.1. Параметр multilabel не может быть включен на /
Параметр multilabel не включается на моем корневом (/) разделе!
Похоже, что каждый пятидесятый пользователь сталкивается с этой проблемой; на самом деле, и у нас была эта проблема в первых настройках. Дальнейшие наблюдения за этой так называемой ''ошибкой'' привели меня к мнению, что это результат или некорректной документации, или неправильной интерпретации этой документации. Независимо от того, почему это случилось, для решения этой проблемы могут быть предприняты следующие шаги:
1. Отредактируйте /etc/fstab и установите для корневого раздела параметр только для чтения (ro).
2. Перегрузитесь в однопользовательский режим.
3. Запустите команду tunefs -l enable на /.
4. Перегрузите систему в нормальный режим.
5. Запустите mount -urw / и измените параметр ro обратно на rw в /etc/fstab; перегрузите систему опять.
6. Дважды проверьте вывод mount, чтобы убедиться, что параметр multilabel был установлен на корневой файловой системе.
15.16.2. Не могу запустить XFree86™ после MAC
После настройки системы безопасности MAC, я больше не могу запускать XFree86!
Это может быть вызвано политикой MAC partition или путем неправильной установки меток одной из политик MAC. Для отладки попробуйте следующее:
1. Просмотрите сообщение об ошибке; если пользователь находится в классе insecure, проблема может быть в политике partition. Попробуйте установить класс пользователя обратно в default и пересобрать базу данных командой cap_mkdb. Если это не решит проблемы, попробуйте шаг два.
|
|
|
2. Дважды проверьте политики с метками. Убедитесь, что политики настроены правильно для рассматриваемого пользователя, приложения XFree86, и устройств в /dev.
3. Если проблема не решена, отправьте сообщение об ошибке и описание вашей системы в список рассылки TrustedBSD, находящийся на веб сайте TrustedBSD (http://www.TrustedBSD.org) или в Список рассылки, посвящённый вопросам и ответам пользователей FreeBSD (http://lists.FreeBSD.org/mailman/listinfo/freebsd-questions).
Error: _secure_path(3) cannot stat .login_conf
При попытке переключения от root на другого пользователя системы, появляется сообщение об ошибке _secure_path: unable to state .login_conf.
Это сообщение обычно показывается, когда у пользователя более высокая метка, чем у пользователя, которым он пытается стать. Например, у пользователя системы joe метка по умолчанию biba/low. Пользователь root, метка которого biba/high, не может просматривать домашний каталог пользователя joe. Это не зависит от того, использует ли пользователь root команду su joe или нет. В этом сценарии модель целостности Biba не позволит root просматривать объекты с низким уровнем целостности.
|
|
|
15.16.4. Пользователя root нет!
В нормальном или даже однопользовательском режиме root не обнаруживается. Команда whoami возвращает 0 (нуль) и su возвращает who are you?. Что можно сделать?
Это может произойти, если политика с метками была отключена, или через sysctl(8), или путем выгрузки модуля политики. Если политика была постоянно или временно отключена, базу данных login необходимо перенастроить. Дважды проверьте login.conf, чтобы убедиться, что все параметры label были удалены и пересоберите базу данных командой cap_mkdb.
Примечания
1. Есть и другие ситуации, в которых могут возникать различные ошибки. Например, файл может не находиться во владении пользователя, пытающегося изменить метку на объекте, объект может не существовать или существовать только для чтения. Политика может не позволить процессу изменить метку на файл, возможно в связи со свойствами файла, процесса, или нового значения метки. Например: пользователь с низким уровнем доверия пытается изменить метку на файле с высоким уровнем доверия. Или пользователь с низким уровнем доверия пытается изменить метку файла с низким уровнем доверия на метку высокого уровня.
2. Вследствие ошибки переменная sysctl security.mac.portacl.enabled не будет работать в FreeBSD 5.2.1 или более ранних релизах.
|
|
|
Глава 16.
Аудит событий безопасности
Краткий обзор
FreeBSD 6.2-RELEASE и более поздние версии FreeBSD включают в себя поддержку аудита событий безопасности. Аудит событий дает надежный и точный способ для протоколирования различных событий, связанных с безопасностью, включая входы в систему, изменения конфигурации, доступ к файлам и сети. Эти записи могут быть незаменимы для мониторинга функционирующей системы, обнаружения вторжений и для анализа событий, приведших к краху системы. В FreeBSD реализован опубликованный Sun BSM API и формат файла, который совместим с реализациями аудита в Sun Solaris и Apple® Mac OS X.
В этой главе описывается, в основном, процесс установки и конфигурирования системы аудита. В том числе, приводится разъяснение политик аудита, а так же даются примеры конфигурационных файлов.
После прочтения этой главы вы будете знать:
• Что такое система аудита и как она работает.
• Как настроить аудит во FreeBSD для мониторинга пользователей и процессов.
• Как просматривать журнал аудита, использовать ограничения по размеру и специальные инструменты для его просмотра.
|
|
|
Перед прочтением этой главы вы должны:
• Понимать основы UNIX и FreeBSD (Гл. 3).
• Уметь конфигурировать и компилировать ядро (Гл. 8).
• Понимать основные принципы безопасности в применении к операционной системе FreeBSD (Гл. 14).
Внимание: Реализация аудита в FreeBSD 6.2 - экспериментальная, использование ее в реальных задачах должно производиться только после внимательного ознакомления со всеми рисками, к которым приводит использование экспериментального программного обеспечения. К известным ограничениям относится и тот факт, что не все события в настоящий момент протоколируемы. Например, некоторые механизмы входа в систему (X11-основанные оконные менеджеры, многое программное обеспечение от сторонних производителей) не сконфигурированы для протоколирования событий входа в систему через подсистему аудита.
Внимание: Использование системы в аудита может привести к генерированию огромных журнальных файлов: их размер на сильно загруженных серверах в некоторых конфигурациях может достигать нескольких гигабайт в неделю. Администраторы должны внимательно следить за дисковым пространством в разделе системы аудита. Например, рекомендуется выделить отдельный раздел для файловой системы аудита /var/audit, чтобы переполнение раздела аудита не влияло на работоспособность всей остальной системы.
Дата добавления: 2018-10-26; просмотров: 174; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!