SUSE a anunțat SLES 16.0 pe 4 noiembrie 2025, SELinux înlocuind AppArmor ca framework implicit de control al accesului obligatoriu. Dacă serverul dvs. rulează SLES 16, nu presupuneți că AppArmor este instalat sau activ: confirmați framework-ul acceptat de implementarea respectivă înainte de a utiliza aceste comenzi. Procedura de mai jos respectă documentația SUSE SLES 15 SP7 AppArmor, unde AppArmor este instalat și rulează în mod implicit.
Pe SLES 15 SP7, calea practică pentru o aplicație personalizată este de a permite aa-genprofcrearea unui profil de pornire, exersarea aplicației în modul de reclamație, revizuirea fiecărei solicitări înregistrate, apoi confirmarea faptului că profilul este aplicabil. Exemplul folosește un executabil ipotetic la /usr/local/bin/report-worker; înlocuiți-l cu calea executabilă reală a aplicației.
Profilurile AppArmor sunt politici text stocate sub /etc/apparmor.d. apparmor-utilsPachetul furnizează instrumentele de profilare. Verificați gazda și identificați executabilul real, inclusiv dacă o unitate systemd lansează un proces wrapper sau un proces copil:
sudo aa-status
command -v aa-genprof
systemctl status apparmor
readlink -f /usr/local/bin/report-worker
SUSE listează AppArmor ca fiind activat în mod implicit la instalările SLES 15. Dacă instrumentele sau modelul complet AppArmor lipsesc, instalați modelul cu sudo zypper in -t pattern apparmor. Dacă AppArmor nu este activ, rezolvați motivul înainte de profilare, în loc să presupuneți că un fișier de profil oferă singur protecție. Un profil este atașat la o cale executabilă; profilarea unui wrapper atunci când sarcina de lucru reală rulează ca un alt fișier binar poate lăsa procesul important nelimitat.
Porniți generatorul. Opriți aplicația dacă aceasta rulează deja, apoi lansați generarea de profiluri:
sudo systemctl stop report-worker
sudo aa-genprof /usr/local/bin/report-worker
Numele serviciului este un exemplu. Folosiți numele real al unității sau omiteți comanda stop dacă programul nu rulează. aa-genprofcreează un profil aproximativ atunci când acesta nu există, îl pune în modul de reclamație (învățare), îl reîncarcă și marchează jurnalul. Modul de reclamație înregistrează solicitările care nu respectă politica, dar le permite; este o stare de învățare temporară, nu de aplicare.
Exersați comportamentul real al aplicației. Mențineți generatorul deschis. Într-un alt terminal, porniți serviciul și rulați joburi sau funcții reprezentative:
sudo systemctl start report-worker
sudo journalctl -f
Acoperă pornirea normală, căile de intrare și ieșire așteptate, sarcinile programate, gestionarea erorilor și orice programe auxiliare lansate de aplicație. Un profil poate învăța doar solicitările generate în timpul testului. Nu utilizați sarcini de lucru sensibile la producție doar pentru a genera evenimente; sunt preferabile un mediu de testare sigur și date de testare reprezentative.
Revizuiți fiecare solicitare de acces. Reveniți la aa-genprofși apăsați Spentru a scana intervalul de jurnal marcat. Pentru fiecare solicitare, decideți dacă aplicația are nevoie cu adevărat de acel fișier, capacitate sau tranziție de la programul copil la program. Permiteți cea mai îngustă cale utilă și permisiune. Acceptați o abstracție atunci când acoperă cu exactitate o sarcină comună; utilizați un glob numai atunci când fișierele potrivite au aceleași cerințe de încredere și acces. Refuzați sau omiteți solicitările care sunt incidentale sau inexplicabile.
Acordați o atenție deosebită executării cererilor. O tranziție nelimitată poate permite unui copil să scape de politica părintelui; utilizați-o numai atunci când există o nevoie justificată de design. Repetați exercițiul și ciclul de scanare după adăugarea regulilor legitime. Când profilul acoperă comportamentul testat, finalizați generatorul. SUSE observă că finalizarea unui nou aa-genprofciclu de învățare pune în mod normal profilul său în modul de aplicare.
Inspectați politica generată. Pentru această cale exemplu, convenția de denumire SUSE convertește barele oblice din calea executabilă în puncte, producând /etc/apparmor.d/usr.local.bin.report-worker. Examinați rezultatul în loc să tratați regulile generate ca fiind automat sigure:
sudo less /etc/apparmor.d/usr.local.bin.report-worker
Verificați dacă profilul denumește executabilul dorit, utilizează include-urile necesare și acordă acces doar la configurație, date, jurnale, socket-uri și programe auxiliare de care aplicația are nevoie. Evitați regulile generale, cum ar fi accesul nerestricționat sub /sau printr-un întreg arbore cu posibilitate de scriere, doar pentru a reduce la tăcere o refuzare. Aplicația depinde în continuare de proprietatea și permisiunile Unix obișnuite; AppArmor adaugă un strat separat de restricții.
Setați explicit modul dorit. După verificare, impuneți profilul pentru programul personalizat:
sudo aa-enforce /usr/local/bin/report-worker
Dacă ați editat profilul manual după închiderea generatorului, reîncărcați setul de profiluri cu sudo systemctl reload apparmor. Documentele SUSE se reîncarcă pe măsură ce rescanează profilurile fără a elibera restricțiile proceselor care rulează. Reporniți serviciul aplicației astfel încât noua politică să se aplice procesului său.
Executați din nou aceleași sarcini reprezentative în timp ce profilul este în modul de aplicare. Confirmați că serviciul pornește, citește intrările intenționate, scrie ieșirea așteptată și poate efectua operațiunile de asistență sau de rețea necesare. Apoi, inspectați atât starea profilului, cât și mesajele recente ale kernelului:
sudo aa-status
sudo journalctl -k -g apparmor --since today
Executabilul personalizat ar trebui să apară ca încărcat și în modul de aplicare. Refuzurile AppArmor din jurnalul kernelului identifică solicitările blocate de politică; folosiți-le pentru a diagnostica o eroare reală a aplicației, nu ca un motiv pentru a permite fiecare cale înregistrată. Pentru o permisiune lipsă legitimă, executați sudo aa-logprof, revizuiți sugestia, actualizați regula în mod restrâns, reîncărcați dacă ați editat manual și rulați din nou calea afectată a aplicației.
Pentru un serviciu care rulează continuu și a cărui profilare trebuie să acopere reporniri sau observații mai lungi, SUSE documentează un flux de lucru sistemic separat folosind aa-autodep, aa-complainși aa-logprofscanări repetate. Metoda independentă aa-genprofeste mai simplă atunci când rularea de învățare poate rămâne deschisă pentru testul complet. Niciun flux de lucru nu poate deduce un comportament al aplicației care nu a fost niciodată exersat, așadar, verificați profilul atunci când se modifică software-ul sau configurația.
Configurați calea corectă pentru Live Patching pentru SLES 16.0 sau 15 SP7, aplicați corecțiile eligibile ale kernelului și confirmați ce este activ fără a-l confunda cu o actualizare a kernelului care necesită repornire.
SLES 15 SP5 poate migra online la SP6, dar fiecare nod trebuie să repornească. Folosiți o actualizare continuă testată sau o trecere de la un sistem blue-green la altul pentru a menține accesibile sarcinile de lucru.
Creați, rafinați și verificați un profil AppArmor cu privilegii minime pe SLES 15 SP7, cu o notă clară privind setările implicite SELinux pentru SLES 16.
Folosește profilul STIG acceptat de SUSE pentru a scana SLES 15, a testa remedierea, a revizui constatările rămase și a păstra dovezile evaluării.
Urmăriți o conexiune Cockpit eșuată prin DNS, portul 9090, socketul systemd, firewalld, TLS și setările de conectare folosind instrucțiunile SUSE actuale.
Creați o conexiune Ethernet redundantă pe SLES 15 cu YaST și Wicked, configurați legătura activă de backup și verificați ambele porturi și failover-ul.
Transformați un sistem SLES 15 existent într-un profil AutoYaST revizuit, validați-l și utilizați-l pentru a implementa un server de testare cu mai puțini pași manuali.
Instalați instrumentele SLES 15 KVM și libvirt, activați serviciul gazdă corect și configurați mașinile virtuale selectate pentru a porni după o repornire.
Fă copii de rezervă ale fișierelor Nextcloud și MariaDB împreună, programează snapshot-uri Restic criptate cu cron și verifică recuperarea fără a risca serverul activ.
Exportați o cutie poștală individuală Zimbra Community Edition, validați copia de rezervă TGZ și restaurați elementele lipsă fără a suprascrie e-mailurile existente.
