Firma SUSE ogłosiła SLES 16.0 4 listopada 2025 r., w którym SELinux zastąpił AppArmor jako domyślną, obowiązkową platformę kontroli dostępu. Jeśli na serwerze działa SLES 16, nie zakładaj, że AppArmor jest zainstalowany lub aktywny: przed użyciem tych poleceń sprawdź, jaka platforma jest obsługiwana przez daną instalację. Poniższa procedura jest zgodna z dokumentacją AppArmor dla SLES 15 SP7 firmy SUSE, w której AppArmor jest domyślnie zainstalowany i uruchomiony.
W systemie SLES 15 SP7 praktyczną ścieżką dla aplikacji niestandardowej jest utworzenie aa-genprofprofilu startowego, sprawdzenie aplikacji w trybie narzekania, przejrzenie każdego zarejestrowanego żądania, a następnie potwierdzenie, że profil wymusza. W przykładzie użyto hipotetycznego pliku wykonywalnego w /usr/local/bin/report-worker; należy go zastąpić rzeczywistą ścieżką wykonywalną aplikacji.
Profile AppArmor to polityki tekstowe przechowywane w /etc/apparmor.d. apparmor-utilsPakiet dostarcza narzędzia do profilowania. Sprawdź hosta i zidentyfikuj rzeczywisty plik wykonywalny, w tym czy jednostka systemd uruchamia wrapper lub proces potomny:
sudo aa-status
command -v aa-genprof
systemctl status apparmor
readlink -f /usr/local/bin/report-worker
SUSE domyślnie włącza AppArmor w instalacjach SLES 15. Jeśli brakuje narzędzi lub pełnego wzorca AppArmor, zainstaluj go za pomocą sudo zypper in -t pattern apparmor. Jeśli AppArmor nie jest aktywny, przed profilowaniem należy ustalić przyczynę, zamiast zakładać, że sam plik profilu zapewnia ochronę. Profil jest dołączony do ścieżki wykonywalnej; profilowanie wrappera, gdy rzeczywiste obciążenie jest uruchamiane jako inny plik binarny, może spowodować, że ważny proces nie będzie ograniczony.
Uruchom generator. Zatrzymaj aplikację, jeśli jest już uruchomiona, a następnie uruchom generowanie profilu:
sudo systemctl stop report-worker
sudo aa-genprof /usr/local/bin/report-worker
Nazwa usługi jest przykładowa. Użyj rzeczywistej nazwy jednostki lub pomiń polecenie stop, jeśli program nie jest uruchomiony. aa-genprofTworzy profil przybliżony, gdy nie istnieje, przełącza go w tryb narzekania (uczenia się), ponownie ładuje i oznacza dziennik. Tryb narzekania rejestruje żądania niezgodne z polityką, ale je zezwala; jest to tymczasowy stan uczenia się, a nie wymuszania.
Przećwicz zachowanie rzeczywistej aplikacji. Pozostaw generator otwarty. W innym terminalu uruchom usługę i uruchom reprezentatywne zadania lub funkcje:
sudo systemctl start report-worker
sudo journalctl -f
Obejmują one normalny rozruch, oczekiwane ścieżki wejściowe i wyjściowe, zaplanowane zadania, obsługę błędów oraz wszelkie programy pomocnicze uruchamiane przez aplikację. Profil może zapamiętywać jedynie żądania generowane podczas testu. Nie należy używać obciążeń wrażliwych na środowisko produkcyjne wyłącznie do generowania zdarzeń; preferowane jest bezpieczne środowisko testowe i reprezentatywne dane testowe.
Przejrzyj każde żądanie dostępu. Wróć do aa-genprofi naciśnij S, aby przeskanować oznaczony zakres logów. W przypadku każdego monitu zdecyduj, czy aplikacja rzeczywiście potrzebuje danego pliku, funkcji lub przejścia między programami potomnymi. Zezwól na najwęższą użyteczną ścieżkę i uprawnienia. Zaakceptuj abstrakcję, gdy dokładnie obejmuje ona typowe zadanie; używaj globu tylko wtedy, gdy dopasowane pliki mają te same wymagania dotyczące zaufania i dostępu. Odrzuć lub pomiń żądania, które są przypadkowe lub niewyjaśnione.
Zwróć szczególną uwagę na żądania wykonania. Nieograniczone przejście może pozwolić dziecku na ominięcie polityki rodzica; stosuj je tylko wtedy, gdy istnieje uzasadniona potrzeba projektowa. Powtórz ćwiczenie i cykl skanowania po dodaniu prawidłowych reguł. Gdy profil obejmie testowane zachowanie, zakończ generator. SUSE zauważa, że ukończenie nowego aa-genprofcyklu uczenia zazwyczaj przełącza profil w tryb wymuszania.
Sprawdź wygenerowaną politykę. W tym przykładowym pliku ścieżka, konwencja nazewnictwa SUSE konwertuje ukośniki w ścieżce wykonywalnej na kropki, generując /etc/apparmor.d/usr.local.bin.report-worker. Sprawdź wynik zamiast traktować wygenerowane reguły jako automatycznie bezpieczne:
sudo less /etc/apparmor.d/usr.local.bin.report-worker
Sprawdź, czy profil nadaje nazwę docelowemu plikowi wykonywalnemu, używa wymaganych elementów include i przyznaje dostęp tylko do konfiguracji, danych, logów, gniazd i programów pomocniczych, których aplikacja faktycznie potrzebuje. Unikaj ogólnych reguł, takich jak nieograniczony dostęp do całego /drzewa lub możliwość zapisu, tylko po to, by uciszyć odmowę. Aplikacja nadal opiera się na standardowej własności i uprawnieniach systemu Unix; AppArmor dodaje osobną warstwę ograniczeń.
Ustaw jawnie zamierzony tryb. Po sprawdzeniu wymuś profil dla programu niestandardowego:
sudo aa-enforce /usr/local/bin/report-worker
Jeśli edytowałeś profil ręcznie po zamknięciu generatora, załaduj ponownie zestaw profili za pomocą sudo systemctl reload apparmor. Dokumenty SUSE ładują się ponownie jako profile ponownego skanowania bez odblokowywania uruchomionych procesów. Uruchom ponownie usługę aplikacji, aby nowa polityka została zastosowana do jej procesu.
Uruchom ponownie te same zadania reprezentatywne, gdy profil jest w trybie wymuszania. Sprawdź, czy usługa uruchamia się, odczytuje odpowiednie dane wejściowe, zapisuje oczekiwane dane wyjściowe i może wykonywać wymagane operacje pomocnicze lub sieciowe. Następnie sprawdź stan profilu i ostatnie komunikaty jądra:
sudo aa-status
sudo journalctl -k -g apparmor --since today
Niestandardowy plik wykonywalny powinien być widoczny jako załadowany i w trybie egzekwowania. Odmowy AppArmor w dzienniku jądra identyfikują żądania zablokowane przez politykę; należy ich używać do diagnozowania rzeczywistej awarii aplikacji, a nie jako powodu do zezwalania na każdą zarejestrowaną ścieżkę. W przypadku uzasadnionego braku uprawnienia, uruchom sudo aa-logprof, zapoznaj się z sugestią, zaktualizuj regułę w wąskim zakresie, przeładuj, jeśli edytowałeś ją ręcznie, i ponownie uruchom ścieżkę aplikacji, której dotyczy problem.
W przypadku usługi działającej w sposób ciągły, której profilowanie musi obejmować restarty lub dłuższą obserwację, SUSE dokumentuje oddzielny, systemowy przepływ pracy, wykorzystujący aa-autodep, aa-complain, oraz powtarzane aa-logprofskanowanie. Metoda autonomiczna aa-genprofjest prostsza, gdy przebieg uczenia się może pozostać otwarty przez cały test. Żaden z przepływów pracy nie jest w stanie wywnioskować zachowania aplikacji, która nigdy nie została przetestowana, dlatego należy regularnie sprawdzać profil w przypadku zmian oprogramowania lub konfiguracji.
Skonfiguruj właściwą ścieżkę Live Patching dla systemu SLES 16.0 lub 15 SP7, zastosuj odpowiednie poprawki jądra i potwierdź, co jest aktywne, nie myląc tego z aktualizacją jądra wymaganą przy ponownym uruchomieniu komputera.
SLES 15 SP5 można migrować online do SP6, ale każdy węzeł wymaga ponownego uruchomienia. Użyj sprawdzonej aktualizacji ciągłej lub przejścia na system Blue-Green, aby utrzymać dostępność obciążeń.
Utwórz, udoskonal i zweryfikuj profil AppArmor o najniższych uprawnieniach w systemie SLES 15 SP7, z czytelną notatką na temat domyślnego ustawienia SELinux w systemie SLES 16.
Użyj obsługiwanego profilu STIG firmy SUSE do skanowania systemu SLES 15, testowania działań naprawczych, przeglądania pozostałych ustaleń i zachowywania dowodów oceny.
Prześledź nieudane połączenie z Cockpitem przez DNS, port 9090, gniazdo systemd, zaporę firewalld, TLS i ustawienia logowania, korzystając z bieżących wskazówek SUSE.
Utwórz redundantne połączenie Ethernet w systemie SLES 15 za pomocą YaST i Wicked, skonfiguruj łączenie aktywnych kopii zapasowych i zweryfikuj oba porty oraz funkcję przełączania awaryjnego.
Przekształć istniejący system SLES 15 w sprawdzony profil AutoYaST, zweryfikuj go i użyj do wdrożenia serwera testowego, wykonując mniej czynności ręcznych.
Zainstaluj narzędzia SLES 15 KVM i libvirt, włącz odpowiednią usługę hosta i skonfiguruj wybrane maszyny wirtualne tak, aby uruchamiały się po ponownym uruchomieniu.
Użyj zadań systemd i poprzedniego dziennika rozruchowego, aby zlokalizować powolną usługę, punkt montowania lub zależność od magazynu, a następnie napraw ją, nie maskując przyczyny.
Użyj polecenia firewall-cmd, aby sprawdzić aktywną strefę, bezpiecznie zezwolić na protokół HTTP, zachować dostęp SSH i zweryfikować, czy reguła przetrwa ponowne załadowanie w systemie SLES 15.
