Главная
» LINUX
»
Как настроить профили AppArmor для пользовательских приложений в SUSE SLES 15
Как настроить профили AppArmor для пользовательских приложений в SUSE SLES 15
Примечание к версии, проверено 6 октября 2026 г.: Данная процедура применима к SUSE Linux Enterprise Server (SLES) 15 SP7 и совместимым системам SLE 15, использующим AppArmor. В документации SUSE указано, что AppArmor установлен и работает по умолчанию в SLES 15 SP7. В SUSE Linux 16.0 AppArmor удален, и вместо него используется SELinux, поэтому не применяйте приведенные ниже команды к версии 16.0; используйте руководство по сравнению SUSE Linux 16.0 и документацию по SELinux для этой версии.
AppArmor — это модуль безопасности Linux, который ограничивает доступ программы к определенным ресурсам. Профиль — это политика, прикрепленная к исполняемому файлу: она может разрешать или запрещать доступ к файлам, возможностям и другим ресурсам. Это руководство проведет вас от подтверждения платформы до применения протестированного профиля, с осторожным этапом обучения, чтобы снизить вероятность неожиданных сбоев в работе пользовательского приложения.
Что нужно подготовить перед созданием профиля?
Если приложение важно, используйте окно тестирования или технического обслуживания. Вам потребуется учетная запись администратора с указанием sudoфактического пути к исполняемому файлу приложения и списка выполняемых им обычных задач. Включите фоновую работу, запуск и завершение работы, перезагрузку конфигурации, загрузку или экспорт, запланированные задания и любые сетевые функции. Профиль, сформированный на основе одного запуска, не сможет определить функции, которые вы никогда не используете.
Узнайте, откуда приложение считывает и записывает данные, под какой учетной записью оно запускается и запускает ли оно вспомогательные процессы. По возможности избегайте тестирования на конфиденциальных производственных данных. Записывайте текущее состояние службы и сохраняйте копию существующего профиля перед внесением изменений.
Как убедиться в доступности AppArmor в этой версии SUSE?
Сначала проверьте версию операционной системы и текущее состояние AppArmor:
cat /etc/os-release
sudo aa-status
Сначала проверьте версию SUSE; приведенная команда считывает файл идентификации операционной системы.Используйте команду aa-status, чтобы проверить, активен ли AppArmor и какие профили загружены.
Убедитесь, что система сообщает о SLES 15 SP7 или другом релизе, документация которого поддерживает AppArmor. В SLES 15 SP7 руководство SUSE указывает, что AppArmor установлен и работает по умолчанию. Если он отсутствует, SUSE описывает его установку с помощью команды ` sudo zypper in -t pattern apparmor.`. Если служба установлена, но не запущена, проверьте политику запуска системы и состояние службы, прежде чем включать ее; не отключайте модуль безопасности, чтобы обойти проблему с приложением. Для получения подробной информации, специфичной для данного релиза, обратитесь к руководству по началу работы с AppArmor в SLES 15 SP7 и руководству по инструментам командной строки AppArmor в SLES 15 SP7 .
Как определить, какой исполняемый файл должен быть профилирован программой AppArmor?
Профили AppArmor связаны с путями к программам, поэтому идентифицируйте фактический исполняемый файл, а не предполагайте, что команда, которую вводит пользователь, является исполняемым файлом. Для команды, доступной через путь к оболочке, выполните:
command -v myapp
Замените myapp на команду приложения и подтвердите полученный путь к исполняемому файлу перед профилированием.
Для проверки службы изучите ее определение модуля и сведения о процессе, используя доступные в вашей системе инструменты. Скрипт запуска, символическая ссылка или интерпретатор могут привести к запуску другого исполняемого файла, чем ожидалось. При readlink -f /path/to/myappнеобходимости определите известный путь. Замените проверенный абсолютный путь в каждой из приведенных ниже команд; /usr/local/bin/myappэто лишь пример.
Перед профилированием проверьте, существует ли уже профиль в каталоге `/etc/profile` /etc/apparmor.d. SUSE хранит профили там, и в имени файла обычно заменяются косые черты в пути к исполняемому файлу точками. Например, `/etc/ /usr/local/bin/myappprofile` соответствует имени файла, например, `/etc/profile` usr.local.bin.myapp. Не перезаписывайте существующий профиль поставщика или локально поддерживаемый профиль без его проверки. SUSE также перечисляет дополнительные профили в каталоге `/etc/profile` /usr/share/apparmor/extra-profiles; подходящий профиль может послужить отправной точкой, но его все равно необходимо проверить для вашего приложения и релиза ( документация по репозиторию профилей SUSE ).
Как безопасно создать первоначальный профиль?
Запустите инструмент для создания профилей от имени администратора, указав полный путь к исполняемому файлу:
sudo aa-genprof /usr/local/bin/myapp
Запустите aa-genprof, указав проверенный путь к исполняемому файлу; приведенный здесь путь является примером для замены.
aa-genprofСоздается начальный профиль, и программа переводится в режим проверки на наличие нарушений, пока вы ее используете. Режим проверки на наличие нарушений регистрирует нарушения политики, но не блокирует запрещенные операции, что позволяет наблюдать за поведением до применения мер принуждения. Следуйте подсказкам инструмента; после запуска приложения используйте функцию сканирования для просмотра зарегистрированных событий. SUSE описывает это как итеративный процесс, а не как гарантию полноты автоматически предложенного профиля.
Какие действия следует проверить и где обнаруживаются отказы в обслуживании?
Пока профиль находится в режиме обработки жалоб, используйте приложение как обычный оператор. Протестируйте стандартные рабочие процессы и менее частые, но поддерживаемые задачи, включая чтение, запись, загрузку, генерацию отчетов, перезапуск служб и вспомогательные задания. Тестирование должно быть реалистичным: программа может использовать разные файлы или дочерние процессы для экспорта и для главного экрана.
Просмотрите сообщения ядра и журнал аудита на предмет событий AppArmor:
sudo journalctl -k | grep -i apparmor
После запуска программы проверьте сообщения ядра на наличие событий AppArmor; эта команда отобразит соответствующие записи, если они присутствуют.
В зависимости от настроек логирования системы, SUSE также указывает на /var/log/audit/audit.log, journalctl | grep -i apparmor, и dmesg -T. Отсутствие совпадения в одном из представлений журнала не доказывает правильность профиля: убедитесь, что приложение было запущено, и проверьте службу логирования и другие указанные места расположения журналов. Не следует считать сгенерированный профиль протестированным только потому, что приложение запускается один раз.
Как следует пересматривать и уточнять профиль?
От имени root используйте команду aa-logprofдля обработки событий, зарегистрированных в журнале, и ответов на запросы:
sudo aa-logprof
Используйте aa-logprof для анализа наблюдаемых обращений и определения того, какие из них подпадают под действие политики приложения.
Для каждого события выясните, необходим ли доступ для выполнения документированной задачи приложения. Разрешайте только узкий путь, режим доступа или возможности, требуемые программой. Чтение файла конфигурации может быть ожидаемым; незапланированная запись в несвязанный каталог может сигнализировать об ошибке или необходимости исследования отдельного компонента. Слишком широкие правила ослабляют ограничение доступа, в то время как слишком узкие правила могут нарушить корректность выполнения допустимых задач.
Не следует автоматически принимать каждое запрос или предоставлять общий доступ ко всем файлам.
Избегайте широких символов-заменителей и ненужных возможностей; отдавайте предпочтение точному пути и минимально необходимым разрешениям.
Повторите цикл обработки нагрузки и проверки журналов после редактирования профиля. Включите отдельные сервисные операции и фоновые задачи.
Вносите изменения только в рамках целевого приложения; не вносите несвязанные изменения в профиль, чтобы заглушить лишнюю информацию.
Профиль представляет собой границу контроля доступа, поэтому на запрос следует отвечать, исходя из поведения приложения и операционных требований, а не просто потому, что он появился в журнале. Руководство по инструментам командной строки SUSE SLES 15 SP7 AppArmor объясняет работу этих инструментов, а в справочных материалах службы поддержки SUSE AppArmor приведены ссылки на соответствующие страницы руководства, включая aa-genprof, aa-logprof, и apparmor_parser.
Когда следует переключать профиль в режим принудительного применения?
Переходите к принудительному применению только после успешного завершения репрезентативных рабочих процессов и проверки легитимных событий. Примените принудительное применение к одному профилю приложения, перезагрузите набор профилей AppArmor и перезапустите приложение или службу, чтобы запущенный процесс использовал обновленную политику:
Примените проверку к целевому профилю, затем перезагрузите AppArmor; замените путь к примеру проверенным исполняемым файлом.
Компания SUSE отмечает, что перезагрузка повторно считывает профили /etc/apparmor.d; для вступления в силу обновленного профиля может потребоваться перезапуск уже запущенной программы. Согласуйте перезапуск с владельцем службы и используйте правильную команду управления службами для приложения. Затем повторите ключевые рабочие процессы в режиме принудительного применения, а не предполагайте, что успешная проверка в режиме жалобы доказывает их работоспособность без изменений.
Как проверить результат и восстановиться после регрессии?
Проверьте состояние профиля и поищите новые отказы после тестирования:
Проверьте загруженный профиль и просмотрите новые сообщения AppArmor после запуска приложения в режиме принудительного применения.
Убедитесь, что нужный профиль загружен и находится в режиме принудительного применения, служба остается работоспособной, и каждая необходимая задача по-прежнему выполняется. Если принудительное применение блокирует законную операцию, соберите соответствующее событие, проверьте, действительно ли требуется доступ, и сузьте область применения профиля. Для краткой контролируемой диагностики sudo aa-complain /usr/local/bin/myappможно перевести профиль программы в режим проверки на наличие ошибок; провести расследование, обновить и повторно протестировать его, прежде чем вернуть в режим принудительного применения aa-enforce. Перезагрузите и перезапустите при необходимости. Избегайте глобального отключения AppArmor или предоставления широких разрешений в качестве быстрого решения проблемы.
Каких распространенных ошибок следует избегать?
Использованы неверные инструкции по выпуску: описанный здесь рабочий процесс предназначен для SLES 15 AppArmor. В SUSE Linux 16.0 вместо этого используется SELinux, согласно руководству по сравнению с SUSE.
Профилирование оболочки вместо реальной программы: проверяйте исполняемый файл, который действительно запускается, особенно это касается служб и скриптов.
Недостаточное обучение: непроверенные признаки не приводят к наблюдаемым обращениям, поэтому неполный профиль может привести к сбою в дальнейшем.
Подтверждение запросов без контекста: каждое добавленное разрешение должно выполнять необходимую задачу приложения.
Чтобы не забывать о перезапуске: перезагрузите профили, а затем перезапустите работающее приложение при необходимости, чтобы процесс принял политику.
Редактирование без возможности отката: создавайте локальные резервные копии профилей и отслеживайте изменения в системе контроля версий или в процессе управления конфигурацией вашей системы.
Эти ссылки были проверены 6 октября 2026 года. Команды и сведения о пакетах могут различаться в зависимости от версии продукта; перед внесением изменений подтвердите наличие документации для конкретного установленного пакета обновлений SLES.