Cum se configurează profilurile AppArmor pentru aplicații personalizate pe SUSE SLES 15

Notă privind versiunea, verificată la 6 octombrie 2026: Această procedură se aplică sistemelor SUSE Linux Enterprise Server (SLES) 15 SP7 și sistemelor SLE 15 compatibile care utilizează AppArmor. SUSE documentează AppArmor ca fiind instalat și rulând în mod implicit pe SLES 15 SP7. SUSE Linux 16.0 elimină AppArmor și utilizează SELinux în schimb, așadar nu aplicați comenzile de mai jos versiunii 16.0; utilizați ghidul de comparare SUSE Linux 16.0 de la SUSE și documentația SELinux pentru versiunea respectivă.

AppArmor este un modul de securitate Linux care restricționează ceea ce poate accesa un program. Un profil este politica atașată unui fișier executabil: poate permite sau refuza accesul la fișiere, capabilități și alte resurse. Acest ghid vă va ghida de la confirmarea platformei până la impunerea unui profil testat, cu o fază de învățare prudentă, astfel încât o aplicație personalizată să fie mai puțin probabilă să se defecteze în mod neașteptat.

Ce ar trebui să pregătești înainte de a-ți crea un profil?

Folosește o fereastră de testare sau de întreținere dacă aplicația este importantă. Ai nevoie de un cont de administrator cu sudo, calea executabilă reală a aplicației și o listă a sarcinilor normale pe care le efectuează. Include lucrările în fundal, pornirea și oprirea, reîncărcările de configurare, încărcările sau exporturile, sarcinile programate și orice funcții conectate la rețea. Un profil învățat dintr-o singură lansare nu poate deduce funcții pe care nu le exersezi niciodată.

Cunoașteți unde citește și scrie aplicația datele, ce cont le rulează și dacă pornește procese auxiliare. Evitați testarea cu date de producție sensibile atunci când este posibil. Înregistrați starea curentă a serviciului și păstrați o copie a oricărui profil existent înainte de a face modificări.

Cum confirmați că AppArmor este disponibil în această versiune de SUSE?

Mai întâi verificați versiunea sistemului de operare și starea curentă a AppArmor:

cat /etc/os-release
sudo aa-status

Confirmați că sistemul raportează SLES 15 SP7 sau o altă versiune a cărei documentație acceptă AppArmor. Pe SLES 15 SP7, ghidul SUSE precizează că AppArmor este instalat și rulează în mod implicit. Dacă lipsește, SUSE documentează instalarea cu sudo zypper in -t pattern apparmor. Dacă serviciul este instalat, dar nu rulează, verificați politica de pornire a sistemului și starea serviciului înainte de a-l activa; nu dezactivați modulul de securitate pentru a rezolva o problemă a aplicației. Consultați ghidul introductiv SLES 15 SP7 AppArmor și ghidul instrumentelor din linia de comandă SLES 15 SP7 AppArmor pentru detalii specifice versiunii.

Cum identifici executabilul pe care AppArmor ar trebui să îl profileze?

Profilurile AppArmor sunt asociate cu căi de programe, așadar identificați executabilul propriu-zis, în loc să presupuneți că utilizatorul comenzii este binar. Pentru o comandă disponibilă prin calea shell, executați:

command -v myapp

Pentru un serviciu, inspectați definiția unității sale și detaliile procesului folosind instrumentele disponibile pe sistemul dvs. Un script de lansare, o legătură simbolică sau un interpretor pot duce la un executabil diferit de cel așteptat. Rezolvați o cale cunoscută cu readlink -f /path/to/myappunde este cazul. Înlocuiți calea absolută verificată în fiecare comandă de mai jos; /usr/local/bin/myappeste doar un exemplu.

Înainte de crearea profilului, verificați dacă există deja un profil sub /etc/apparmor.d. SUSE stochează profilurile acolo, iar numele fișierului înlocuiește de obicei barele oblice din calea executabilă cu puncte. De exemplu, /usr/local/bin/myappse mapează la un nume de fișier precum usr.local.bin.myapp. Nu suprascrieți un profil existent al furnizorului sau întreținut local fără a-l revizui. SUSE listează, de asemenea, profiluri suplimentare sub /usr/share/apparmor/extra-profiles; un profil adecvat poate oferi un punct de plecare, dar trebuie totuși revizuit pentru aplicația și versiunea dvs. ( documentația depozitului de profiluri SUSE ).

Cum generezi un profil inițial în siguranță?

Rulați instrumentul de generare a profilurilor ca administrator, utilizând calea completă executabilă:

sudo aa-genprof /usr/local/bin/myapp

aa-genprofcreează un profil de pornire și plasează programul în modul de reclamație în timp ce îl exersați. Modul de reclamație înregistrează încălcările politicii, dar nu blochează operațiunea refuzată, ceea ce vă permite să observați comportamentul înainte de aplicare. Urmați instrucțiunile instrumentului; după exersarea aplicației, utilizați opțiunea de scanare pentru a revizui evenimentele înregistrate. SUSE descrie acest lucru ca un proces iterativ, nu o garanție că profilul sugerat automat este complet.

Ce acțiuni ar trebui să testați și unde găsiți refuzuri?

În timp ce profilul este în modul de reclamație, utilizați aplicația așa cum ar face-o un operator normal. Testați fluxurile de lucru obișnuite și sarcinile mai puțin frecvente, dar acceptate, inclusiv citiri, scrieri, încărcări, generare de rapoarte, reporniri de servicii și joburi auxiliare. Mențineți testul realist: un program poate utiliza fișiere sau procese fiu diferite pentru un export decât pentru ecranul său principal.

Examinați mesajele kernelului și jurnalul de audit pentru evenimentele AppArmor:

sudo journalctl -k | grep -i apparmor

În funcție de configurarea jurnalizării sistemului, SUSE indică și către /var/log/audit/audit.log, journalctl | grep -i apparmor, și dmesg -T. Lipsa unei potriviri într-o vizualizare a jurnalului nu dovedește că profilul este corect: verificați dacă aplicația a fost executată și verificați serviciul de înregistrare și alte locații documentate ale jurnalelor. Nu tratați un profil generat ca fiind testat doar pentru că aplicația pornește o singură dată.

Cum ar trebui să revizuiți și să rafinați profilul?

Ca root, folosește aa-logprofpentru a procesa evenimentele înregistrate și a răspunde la solicitări:

sudo aa-logprof

Pentru fiecare eveniment, întrebați dacă accesul este necesar pentru o sarcină documentată a aplicației. Permiteți doar calea îngustă, modul de acces sau capacitatea de care are nevoie programul. Se poate aștepta o citire a fișierului de configurare; o scriere neplanificată într-un director fără legătură poate semnala o eroare sau o componentă separată care necesită investigare. Regulile prea largi slăbesc limitarea restricțiilor, în timp ce regulile prea restrânse pot încălca sarcinile valide.

• Nu acceptați automat fiecare solicitare și nu adăugați acces general la toate fișierele.
• Evitați caracterele wildcard largi și capabilitățile inutile; preferați o cale precisă și cele mai mici permisiuni necesare.
• Repetați ciclul de verificare a volumului de lucru și a jurnalelor după modificările profilului. Includeți operațiuni de service separate și sarcini de fundal.
• Păstrați modificările limitate la aplicația țintă; nu faceți modificări de profil fără legătură pentru a reduce la tăcere zgomotul.

Profilul este o limită de control al accesului, așadar un răspuns la o solicitare ar trebui să se bazeze pe comportamentul aplicației și pe cerințele operaționale, nu doar pentru că a apărut într-un jurnal. Ghidul instrumentelor din linia de comandă SUSE SLES 15 SP7 AppArmor explică instrumentele din linia de comandă, iar linkurile de referință pentru asistența SUSE AppArmor către paginile de manual relevante, inclusiv aa-genprof, aa-logprofși apparmor_parser.

Când ar trebui să comutați profilul în modul de aplicare?

Treceți la aplicare numai după ce fluxurile de lucru reprezentative au reușit și ați revizuit evenimentele legitime. Aplicați profilul aplicației, reîncărcați setul de profiluri AppArmor și reporniți aplicația sau serviciul astfel încât procesul care rulează să utilizeze politica actualizată:

sudo aa-enforce /usr/local/bin/myapp
sudo systemctl reload apparmor

SUSE notează că reîncărcarea citește din nou profilurile /etc/apparmor.d; un program care rulează deja poate necesita repornire înainte ca profilul actualizat să aibă efect. Coordonați această repornire cu proprietarul serviciului și utilizați comanda corectă de gestionare a serviciilor pentru aplicație. Apoi, repetați fluxurile de lucru cheie aflate sub aplicare, în loc să presupuneți că succesul modului de reclamație dovedește că acestea vor funcționa neschimbate.

Cum verifici rezultatul și cum te recuperezi după o regresie?

Verificați starea profilului și căutați noi refuzuri după testare:

sudo aa-status
sudo journalctl -k | grep -i apparmor

Confirmați că profilul dorit este încărcat și în modul de aplicare, serviciul rămâne funcțional și fiecare sarcină necesară funcționează în continuare. Dacă aplicarea blochează o operațiune legitimă, colectați evenimentul relevant, verificați dacă accesul este într-adevăr necesar și rafinați profilul în mod restrâns. Pentru un diagnostic scurt și controlat, sudo aa-complain /usr/local/bin/myappputeți pune profilul programului respectiv în modul de reclamație; investigați, actualizați și retestați înainte de a-l readuce în modul de aplicare cu aa-enforce. Reîncărcați și reporniți după cum este necesar. Evitați dezactivarea AppArmor global sau acordarea de permisiuni largi ca soluție rapidă.

Ce greșeli frecvente ar trebui să eviți?

• Utilizarea instrucțiunilor de lansare greșite: fluxul de lucru de aici este pentru SLES 15 AppArmor. SUSE Linux 16.0 folosește în schimb SELinux, conform ghidului de comparație SUSE.
• Profilarea unui wrapper în loc de programul real: verificați executabilul care rulează efectiv, în special pentru servicii și scripturi.
• Învățare prea puțină: caracteristicile netestate nu generează accese observate, așadar un profil incomplet poate eșua ulterior.
• Aprobarea solicitărilor fără context: fiecare permisiune adăugată ar trebui să deservească o sarcină necesară a aplicației.
• Uitând repornirea: reîncărcați profilurile, apoi reporniți o aplicație care rulează atunci când este necesar, astfel încât procesul să adopte politica.
• Editare fără o cale de revenire: creați copii de rezervă ale profilurilor întreținute local și urmăriți modificările în controlul versiunilor sau în procesul de gestionare a configurației sistemului.

Referințe oficiale SUSE

• Ghid introductiv pentru SLES 15 SP7 AppArmor
• Ghidul instrumentelor din linia de comandă AppArmor pentru SLES 15 SP7
• Documentația depozitului de profiluri SUSE
• Referință de asistență SUSE AppArmor
• Ghid comparativ SUSE Linux 16.0

Aceste referințe au fost verificate pe 6 octombrie 2026. Comenzile și detaliile pachetului pot varia în funcție de versiunea produsului; confirmați documentația pentru pachetul service pack SLES exact instalat înainte de a face modificări.