Компания SUSE анонсировала SLES 16.0 4 ноября 2025 года, в котором SELinux заменил AppArmor в качестве обязательной системы контроля доступа по умолчанию. Если на вашем сервере установлена SLES 16, не следует предполагать, что AppArmor установлен или активен: перед использованием этих команд убедитесь, какая система поддерживается в данном развертывании. Приведенная ниже процедура соответствует документации SUSE по AppArmor для SLES 15 SP7, где AppArmor установлен и работает по умолчанию.
В SLES 15 SP7 практический путь для пользовательского приложения заключается в aa-genprofсоздании начального профиля, запуске приложения в режиме обработки жалоб, анализе каждого зарегистрированного запроса, а затем подтверждении корректности профиля. В примере используется гипотетический исполняемый файл по адресу /usr/local/bin/report-worker; замените его реальным путем к исполняемому файлу вашего приложения.
Профили AppArmor представляют собой текстовые политики, хранящиеся в папке /etc/apparmor.d. apparmor-utilsПакет предоставляет инструменты профилирования. Проверьте хост и определите фактический исполняемый файл, в том числе, запускает ли модуль systemd оболочку или дочерний процесс:
sudo aa-status
command -v aa-genprof
systemctl status apparmor
readlink -f /usr/local/bin/report-worker
В SUSE указано, что AppArmor включен по умолчанию в установках SLES 15. Если отсутствуют инструменты или полный шаблон AppArmor, установите его с помощью команды ` sudo zypper in -t pattern apparmor.`. Если AppArmor не активен, выясните причину перед профилированием, а не предполагайте, что одного файла профилирования достаточно для защиты. Профиль прикрепляется к пути исполняемого файла; профилирование оболочки, когда реальная рабочая нагрузка выполняется как другой исполняемый файл, может оставить важный процесс незащищенным.
Запустите генератор. Остановите приложение, если оно уже запущено, затем запустите генерацию профиля:
sudo systemctl stop report-worker
sudo aa-genprof /usr/local/bin/report-worker
Название службы приведено в качестве примера. Используйте реальное имя юнита или опустите команду остановки, если программа не запущена. aa-genprofСоздается приблизительный профиль, если он отсутствует, он переводится в режим жалоб (обучения), перезагружается и помечается в журнале. В режиме жалоб регистрируются запросы, выходящие за рамки политики, но они разрешены; это временное состояние обучения, а не принудительное применение правил.
Протестируйте работу приложения в реальных условиях. Оставьте генератор открытым. В другом терминале запустите службу и выполните показательные задания или функции:
sudo systemctl start report-worker
sudo journalctl -f
Профилирование должно охватывать обычный запуск приложения, ожидаемые пути ввода и вывода, запланированные задачи, обработку ошибок и любые вспомогательные программы, запускаемые приложением. Профиль может обучаться только запросам, генерируемым во время тестирования. Не используйте критически важные для производственной среды рабочие нагрузки только для генерации событий; предпочтительнее безопасная тестовая среда и репрезентативные тестовые данные.
Просматривайте каждый запрос на доступ. Вернитесь назад aa-genprofи нажмите, Sчтобы просканировать отмеченный диапазон журнала. Для каждого запроса определите, действительно ли приложению нужен этот файл, возможность или переход дочерней программы. Разрешите самый узкий полезный путь и разрешение. Принимайте абстракцию, если она точно описывает общую задачу; используйте шаблон только тогда, когда соответствующие файлы имеют одинаковые требования к доверию и доступу. Отклоняйте или пропускайте запросы, которые являются случайными или необъяснимыми.
Обратите особое внимание на запросы на выполнение. Неограниченный переход может позволить дочернему элементу обойти политику родительского элемента; используйте его только при наличии обоснованной проектной необходимости. Повторите упражнение и цикл сканирования после добавления допустимых правил. Когда профиль охватит тестируемое поведение, завершите генератор. SUSE отмечает, что завершение нового aa-genprofцикла обучения обычно переводит профиль в режим принудительного применения.
Проверьте сгенерированную политику. В этом примере пути соглашение об именовании SUSE преобразует косые черты в пути к исполняемому файлу в точки, в результате чего получается /etc/apparmor.d/usr.local.bin.report-worker. Просмотрите результат, вместо того чтобы считать сгенерированные правила автоматически безопасными:
sudo less /etc/apparmor.d/usr.local.bin.report-worker
Убедитесь, что профиль указывает имя целевого исполняемого файла, использует необходимые включаемые файлы и предоставляет доступ только к конфигурации, данным, журналам, сокетам и вспомогательным программам, которые действительно необходимы приложению. Избегайте общих правил, таких как неограниченный доступ /или доступ ко всему дереву файлов с правами записи, только для того, чтобы подавить отказ. Приложение по-прежнему зависит от обычных прав владения и разрешений Unix; AppArmor добавляет отдельный уровень ограничений.
Укажите желаемый режим явным образом. После проверки примените профиль к пользовательской программе:
sudo aa-enforce /usr/local/bin/report-worker
Если вы редактировали профиль вручную после завершения работы генератора, перезагрузите набор профилей с помощью команды ` sudo systemctl reload apparmor.suse`. В документации SUSE указано, что перезагрузка происходит путем повторного сканирования профилей без разблокировки запущенных процессов. Перезапустите службу приложения, чтобы новая политика применялась к ее процессу.
Повторите те же самые задачи, пока профиль находится в режиме принудительного выполнения. Убедитесь, что служба запускается, считывает необходимые входные данные, записывает ожидаемые выходные данные и может выполнять необходимые вспомогательные или сетевые операции. Затем проверьте состояние профиля и последние сообщения ядра:
sudo aa-status
sudo journalctl -k -g apparmor --since today
Пользовательский исполняемый файл должен отображаться как загруженный и в режиме принудительного применения. Отказы AppArmor в журнале ядра идентифицируют запросы, заблокированные политикой; используйте их для диагностики реального сбоя приложения, а не как причину для разрешения всех зарегистрированных путей. Для легитимного отсутствия разрешения запустите команду, sudo aa-logprofпросмотрите предложение, обновите правило, если вы редактировали его вручную, перезагрузите его и повторно запустите затронутый путь приложения.
Для постоянно работающей службы, профилирование которой должно охватывать перезагрузки или более длительное наблюдение, SUSE описывает отдельный системный рабочий процесс с использованием aa-autodep, aa-complain, и повторных aa-logprofсканирований. Автономный aa-genprofметод проще, когда процесс обучения может оставаться открытым в течение всего теста. Ни один из рабочих процессов не может определить поведение приложения, которое никогда не использовалось, поэтому следует постоянно пересматривать профилирование при изменении программного обеспечения или конфигурации.
Настройте правильный путь для установки патчей в режиме реального времени для SLES 16.0 или 15 SP7, примените подходящие исправления ядра и подтвердите, какие обновления активны, не путая их с обновлениями ядра, требующими перезагрузки.
SLES 15 SP5 можно перенести в онлайн-режиме на SP6, но для этого потребуется перезагрузка каждого узла. Используйте проверенное поэтапное обновление или переключение по принципу «сине-зеленого перехода», чтобы обеспечить доступность рабочих нагрузок.
Создайте, уточните и проверьте профиль AppArmor с минимальными привилегиями в SLES 15 SP7, с четким указанием на настройки SELinux по умолчанию в SLES 16.
Используйте поддерживаемый SUSE профиль STIG для сканирования SLES 15, тестирования исправлений, анализа оставшихся проблем и сохранения результатов оценки.
Отследите сбой подключения к Cockpit через DNS, порт 9090, сокет systemd, firewalld, TLS и параметры входа в систему, используя текущие рекомендации SUSE.
Создайте резервное Ethernet-соединение на SLES 15 с помощью YaST и Wicked, настройте активное резервирование и проверьте работу обоих портов и переключение на резервный канал.
Превратите существующую систему SLES 15 в проверенный профиль AutoYaST, проверьте его и используйте для развертывания тестового сервера с меньшим количеством ручных операций.
Установите инструменты SLES 15 KVM и libvirt, включите нужную службу хоста и настройте выбранные виртуальные машины для запуска после перезагрузки.
Используйте задания systemd и журнал предыдущей загрузки, чтобы найти медленно работающую службу, точку монтирования или зависимость хранилища, а затем устраните проблему, не скрывая причину.
Используйте firewall-cmd для проверки активной зоны, безопасного разрешения HTTP-трафика, сохранения доступа по SSH и проверки того, что правило сохраняется после перезагрузки в SLES 15.
