Een aangepast AppArmor-profiel maken op SUSE Linux

SUSE kondigde SLES 16.0 aan op 4 november 2025, waarbij SELinux AppArmor vervangt als het standaard verplichte toegangsbeheerframework. Als uw server SLES 16 gebruikt, ga er dan niet vanuit dat AppArmor is geïnstalleerd of actief is: controleer welk framework door uw implementatie wordt ondersteund voordat u deze opdrachten gebruikt. De onderstaande procedure volgt de SUSE SLES 15 SP7 AppArmor-documentatie, waarin AppArmor standaard is geïnstalleerd en actief is.

In SLES 15 SP7 is de praktische aanpak voor een aangepaste applicatie om aa-genprofeen ​​startprofiel aan te maken, de applicatie in de 'complaint'-modus te testen, elk geregistreerd verzoek te controleren en vervolgens te bevestigen dat het profiel wordt afgedwongen. Het voorbeeld gebruikt een hypothetisch uitvoerbaar bestand op /usr/local/bin/report-worker; vervang dit door het daadwerkelijke pad naar het uitvoerbare bestand van uw applicatie.

Voordat je begint

AppArmor-profielen zijn tekstbeleidsregels die zijn opgeslagen onder /etc/apparmor.d. Het apparmor-utilspakket levert de profileringstools. Controleer de host en identificeer het daadwerkelijke uitvoerbare bestand, inclusief of een systemd-eenheid een wrapper- of subproces start:

sudo aa-status
command -v aa-genprof
systemctl status apparmor
readlink -f /usr/local/bin/report-worker

SUSE vermeldt AppArmor als standaard ingeschakeld op SLES 15-installaties. Als de tools of het volledige AppArmor-patroon ontbreken, installeer het patroon dan met ` sudo zypper in -t pattern apparmornpm install appArmor`. Als AppArmor niet actief is, zoek dan eerst uit waarom dit het geval is voordat u gaat profileren, in plaats van ervan uit te gaan dat een profielbestand alleen al bescherming biedt. Een profiel is gekoppeld aan een uitvoerbaar pad; het profileren van een wrapper terwijl de daadwerkelijke workload als een ander binair bestand draait, kan ertoe leiden dat het belangrijke proces niet wordt beschermd.

Maak en verfijn het profiel

1. Start de generator. Stop de applicatie als deze al actief is en start vervolgens de profielgeneratie:

   sudo systemctl stop report-worker
   sudo aa-genprof /usr/local/bin/report-worker

   

   De servicenaam is een voorbeeld. Gebruik de echte eenheidsnaam of laat de stopopdracht weg als het programma niet actief is. aa-genprofEr wordt een benaderend profiel aangemaakt als er geen bestaat, het wordt in de klachtenmodus (leermodus) gezet, opnieuw geladen en in het logboek gemarkeerd. De klachtenmodus registreert verzoeken die niet aan het beleid voldoen, maar staat deze wel toe; het is een tijdelijke leerfase, geen handhavingsfase.

2. Oefen het daadwerkelijke applicatiegedrag. Houd de generator open. Start in een andere terminal de service en voer representatieve taken of functies uit:

   sudo systemctl start report-worker
   sudo journalctl -f

   

   Dek de normale opstartprocedure, de verwachte invoer- en uitvoerpaden, geplande taken, foutafhandeling en alle hulpprogramma's die de applicatie uitvoert. Een profiel kan alleen verzoeken leren die tijdens de test worden gegenereerd. Gebruik geen productiegevoelige workloads alleen om gebeurtenissen te genereren; een veilige testomgeving en representatieve testgegevens hebben de voorkeur.

3. Bekijk elk toegangsverzoek. Ga terug naar aa-genprofen druk op Som het gemarkeerde logbereik te scannen. Bepaal voor elke prompt of de toepassing het bestand, de functionaliteit of de overgang tussen subprogramma's daadwerkelijk nodig heeft. Sta het meest bruikbare pad en de meest beperkte machtiging toe. Accepteer een abstractie wanneer deze een veelvoorkomende taak nauwkeurig dekt; gebruik een glob-patroon alleen wanneer de overeenkomende bestanden dezelfde vertrouwens- en toegangsvereisten hebben. Weiger of sla verzoeken over die incidenteel of onverklaard zijn.

   

   Besteed speciale aandacht aan uitvoeringsverzoeken. Een ongecontroleerde overgang kan ervoor zorgen dat een kind het beleid van de ouder omzeilt; gebruik deze alleen wanneer er een gerechtvaardigde ontwerpbehoefte is. Herhaal de oefening en de scancyclus na het toevoegen van legitieme regels. Wanneer het profiel het geteste gedrag dekt, beëindigt u de generator. SUSE merkt op dat het voltooien van een nieuwe aa-genprofleercyclus het profiel normaal gesproken in de handhavingsmodus zet.

4. Controleer het gegenereerde beleid. Voor dit voorbeeldpad zet de naamgevingsconventie van SUSE schuine strepen in het uitvoerbare pad om in punten, wat resulteert in /etc/apparmor.d/usr.local.bin.report-worker. Bekijk het resultaat in plaats van gegenereerde regels automatisch als veilig te beschouwen:

   sudo less /etc/apparmor.d/usr.local.bin.report-worker

   

   Controleer of het profiel de naam van het beoogde uitvoerbare bestand correct weergeeft, de vereiste includes gebruikt en alleen toegang verleent tot de configuratie, data, logs, sockets en hulpprogramma's die de applicatie daadwerkelijk nodig heeft. Vermijd algemene regels zoals onbeperkte toegang tot /een volledige beschrijfbare mapstructuur, enkel om een ​​weigering te verbergen. De applicatie is nog steeds afhankelijk van de normale Unix-eigendomsrechten en -rechten; AppArmor voegt een aparte beperkingslaag toe.

5. Stel de gewenste modus expliciet in. Na controle dient u het profiel voor het aangepaste programma af te dwingen:

   sudo aa-enforce /usr/local/bin/report-worker

   

   Als u het profiel handmatig hebt bewerkt nadat de generator is afgesloten, laadt u de profielset opnieuw met sudo systemctl reload apparmor. SUSE-documenten worden opnieuw geladen als profielen die opnieuw worden gescand zonder de beperkingen van actieve processen op te heffen. Start de applicatieservice opnieuw zodat het nieuwe beleid op het bijbehorende proces van toepassing is.

Controleer de toepassing die wordt gehandhaafd.

Voer dezelfde representatieve taken opnieuw uit terwijl het profiel in de afdwingmodus staat. Controleer of de service start, de beoogde invoer leest, de verwachte uitvoer schrijft en de vereiste hulp- of netwerkbewerkingen kan uitvoeren. Inspecteer vervolgens zowel de profielstatus als recente kernelberichten:

sudo aa-status
sudo journalctl -k -g apparmor --since today

Het aangepaste uitvoerbare bestand moet geladen en in de handhavingsmodus verschijnen. AppArmor-weigeringen in het kernellogboek geven aan welke verzoeken door het beleid zijn geblokkeerd; gebruik deze om een ​​daadwerkelijke applicatiefout te diagnosticeren, niet als reden om elk geregistreerd pad toe te staan. Voor een legitieme ontbrekende toestemming, voer het commando uit sudo aa-logprof, bekijk de suggestie, pas de regel nauwkeurig aan, herlaad het programma als u de regel handmatig hebt bewerkt en voer het betreffende applicatiepad opnieuw uit.

Voor een continu draaiende service waarvan de profilering meerdere herstarts of langere observatieperioden moet omvatten, beschrijft SUSE een aparte systeemworkflow met behulp van aa-autodep, aa-complain, en herhaalde aa-logprofscans. De standalone- aa-genprofmethode is eenvoudiger wanneer de leerrun gedurende de volledige test open kan blijven. Geen van beide workflows kan applicatiegedrag afleiden dat nooit is getest, dus blijf het profiel controleren wanneer software- of configuratiewijzigingen worden doorgevoerd.

Bronnen

• SUSE: Wat is er nieuw in SUSE Linux Enterprise Server 16.0?
• SUSE SLES 15 SP7: Aan de slag met AppArmor
• SUSE SLES 15 SP7: Profielen bouwen vanaf de opdrachtregel
• SUSE SLES 15 SP7: Profielcomponenten en syntaxis