Slik bruker du AppArmor på Linux og oppdager skriptendringer

Hvis du jobber med GNU/Linux og er bekymret for sikkerheten til skriptene og tjenestene dine, vil du før eller siden støte på AppArmor som en nøkkelkomponent for å kontrollere hva hver prosess kan gjøreDet er ikke bare for å herde systemet: når det brukes riktig, hjelper det deg også med å finne ut når noe endres der det ikke skal, for eksempel i koden til en script delikat.

I de følgende linjene skal vi se, ganske rolig, men rett på sak, Hva er AppArmor, og hvordan er det sammenlignet med andre systemer som SELinux?, hvordan du aktiverer og administrerer det i de vanligste distribusjonene (spesielt Debian og Ubuntu), hvordan du oppretter og justerer dine egne profiler, og til slutt, hvordan du kan dra nytte av alt dette sammen med noen enkle skallteknikker for å oppdage endringer i skriptkode eller kataloger i Linux uten behov for å sette opp sanntidsovervåking.

Hva er AppArmor, og hvorfor er det viktig for skriptene dine?

AppArmor (applikasjonsrustning) er en obligatorisk tilgangskontrollmekanisme, eller MACintegrert i Linux-kjernen gjennom Linux Security Modules (LSM)-grensesnittet. I stedet for å utelukkende stole på klassiske bruker-/gruppetillatelser (den tradisjonelle DAC-modellen), legger den til et ekstra lag som strengt definerer hva hvert program kan gjøre.

I praksis spør kjernen AppArmor før du utfører visse systemkall (åpne filer, opprette sokkeler, kjøre andre binærfiler, bruke bestemte funksjoner osv.) for å avgjøre om den forespørrende prosessen er autorisert i henhold til sikkerhetsprofilen. Hvis regelen tillater det, kjøres den; hvis ikke, blokkeres eller logges den, avhengig av modusen.

Den grunnleggende enheten i AppArmor er Profilenet sett med regler som er knyttet til en kjørbar fil identifisert av dens absolutte sti, for eksempel /usr/sbin/sshd o /bin/pingI motsetning til SELinux, Reglene for en profil gjelder likt for alle brukere som kjører den binærfilen; tillatelsene Unix Tradisjonelle finnes fortsatt, men AppArmor går langt utover det vanlige og definerer omfanget ytterligere.

Profiler lagres som rene tekstfiler i /etc/apparmor.d/ og lastes vanligvis inn i kjernen i løpet av bootHver profil kan kjøres i modus streng (håndheve)der brudd blokkeres og logges, eller i modus avslappet (klage)der de er tillatt, men er registrert i logger å gjennomgå dem senere.

Historisk sett ble AppArmor lansert av Novell i 2005 og ble primært brukt i SUSE og openSUSECanonical tok den imidlertid med i kjernens hovedlinje fra og med versjon 2.6.36. I dag er den inkludert som standard i mange distribusjoner som Ubuntu og dets derivater eller Debian (aktivert fra Debian 10 og utover), mens andre som Fedora eller RHEL ikke gjør det. De fortsetter å stole på SELinux som sin primære MAC-løsning.

DAC, MAC, AppArmor og SELinux: hvordan er de forskjellige?

For å forstå hva AppArmor bringer til bordet, er det nyttig å skille mellom to tillatelsesmodeller som eksisterer side om side i Linux: DAC (diskresjonær tilgangskontroll) og MAC (obligatorisk tilgangskontroll)DAC-en er den du alltid har kjent: eier, gruppe, andre, deler rwxACL-er osv. Hver bruker kan administrere sine filtillatelser innenfor visse grenser.

MAC-modellen, på sin side, Det er ikke skjønnsmessigTilgangsbeslutninger er basert på globale retningslinjer definert av administratoren og håndhevet av systemet, uavhengig av hvem som eier en fil. Det er her AppArmor og SELinux kommer inn i bildet, begge fungerer som to distinkte MAC-implementeringer under LSM-grensesnittetmen med svært forskjellige bruksfilosofier.

SELinux bruker sikkerhetsetiketter (kontekster) knyttet til prosesser, filer, sokler osv., og tar avgjørelser basert på kombinasjoner av etiketter pluss roller, typer og annen sjargong. Dette gir det ekstremt detaljert kontroll, men også høy kompleksitet både administrasjon og revisjon. AppArmor, derimot, er basert på filstierEn profil er knyttet til en spesifikk bane til den kjørbare filen og beskriver hvilke ressurser den binærfilen kan bruke.

Dette gjør at AppArmor-profiler vanligvis er enklere å lese, skrive og vedlikeholde for den gjennomsnittlige administratoren. Til gjengjeld ofres noe av fleksibiliteten til SELinux, noe som gir kontroll over flere typer operasjoner og scenarier. I mange distribusjoner har AppArmor blitt et veldig praktisk alternativ for herde vanlige tjenester uten å bli helt vanvittig med syntaks.

I forbindelse med skript og automatiseringer lar AppArmor deg begrense hva et gitt skript kan gjøre (for eksempel hvilke kataloger det kan lese eller endre, eller om det kan åpne nettverkstilkoblinger), og takket være klagemodusen kan det også oppdage uventet tilgang før de i det hele tatt blokkeres.

AppArmor-statuser, profiler og overvåking

Før du bruker AppArmor for å beskytte noe, bør du sjekke om det faktisk fungerer på systemet ditt. I moderne distribusjoner som Ubuntu eller Debian er det vanligvis integrert, men Ikke alle profiler er alltid aktive, og de er heller ikke alle i håndhevingsmodus.så det er verdt å ta en titt.

For raskt å sjekke om AppArmor er aktivert, du kan bruke:

sudo aa-enabled

Denne kommandoen svarer i utgangspunktet med en «Ja» hvis modulen er aktiv eller et "Nei" ellers (for eksempel hvis kjernen ikke ble startet med AppArmor-støtte eller tjenesten ikke er lastet inn).

Hvis du vil se detaljene for alle opplastede profiler og statusen deres, tastekommando er:

sudo aa-status

Utgangen av aa-status Den viser blant annet antall lastede profiler, hvor mange som er i håndhevingsmodus, hvor mange som er i klagemodus og listen over ruter som er knyttet til hver enkelt. Denne informasjonen er svært nyttig for å ha en Raskt overblikk over det faktiske beskyttelsesnivået AppArmor tilbyr på maskinen din.

For eksempel kan du se noe som ligner på:

apparmor module is loaded.
46 profiles are loaded.
44 profiles are in enforce mode.
/snap/bin/evince
/snap/bin/evince/previewer
...
2 profiles are in complain mode.
/snap.code.code
...

Jo flere profiler som er i modus håndheveJo strengere den globale politikken er, desto mer effektiv vil den være. Profiler i modus klager De blokkerer ikke transaksjoner, men de logger alle brudd, noe som er svært verdifullt for Juster profiler uten å ødelegge tjenester eller for å revidere hva et program prøver å gjøre.

Installere og aktivere AppArmor på Debian og Ubuntu

I nåværende Debian- og Ubuntu-modeller er AppArmor-støtte allerede inkludert i standardkjernen, så Aktivering av systemet handler om å installere de nødvendige pakkene og sørge for at modulen starter opp. i systemoppstarten.

apt -y install apparmor apparmor-profiles apparmor-utils

El paquete apparmor-utils Den tilbyr nettbaserte verktøy for kommandoer for å sjekke stater (aa-status), endre profilmoduser (aa-enforce, aa-complain), opprett nye profiler (aa-genprof), gjennomgå logger (aa-logprof), Etc.

I noen miljøer kan det også være nødvendig tving kjernen til å starte opp med AppArmor som et aktivt LSM-system. En typisk måte i Ubuntu er å legge til parameterne i GRUB med:

perl -pi -e 's,GRUB_CMDLINE_LINUX="(.*)"$,GRUB_CMDLINE_LINUX="$1 apparmor=1 security=apparmor",' /etc/default/grub
update-grub
reboot

Etter omstart skal AppArmor lastes inn, noe du kan bekrefte med aa-status o apparmor_status (sistnevnte er et veldig vanlig alternativt navn).

Hvis du trenger å utvide samlingen av forhåndsdefinerte profiler som vedlikeholdes av fellesskapet, kan du også installere:

apt install apparmor-profiles-extra

Disse tilleggsprofilene dekker et godt antall tjenester og applikasjoner, mange av dem eksponert for nettverket og spesielt interessant å begrense.

Grunnleggende profiladministrasjon: håndheve, klage, deaktivere og laste inn på nytt

Når du har AppArmor oppe og går, er nøkkelen å administrere profiler riktig. Hver fil i /etc/apparmor.d/ Den definerer reglene for en profil, og navnet tilsvarer vanligvis den kjørbare banen, og erstatter skråstrekene med punktum. For eksempel, /etc/apparmor.d/bin.ping er profilen til /bin/ping.

Normalt sett burde du ikke måtte redigere disse filene manuelt for å endre modusen; det er det andre verktøy er til for. spesifikke verktøyFor eksempel å tvinge en bestemt profil inn i streng modus (håndhev) du kan bruke:

sudo aa-enforce /usr/sbin/cupsd

Hvis du derimot ønsker å opprette en profil i avslappet modus (klage) Fordi du mistenker at det forårsaker problemer, eller du ønsker å finjustere det uten å blokkere trafikk, bør du gjøre følgende:

sudo aa-complain /usr/sbin/privoxy

Disse kommandoene godtar både den kjørbare banen og sti til profilfilenFaktisk, hvis du vil endre den globale modusen for alle profiler som er definert i /etc/apparmor.d/Du kan kjøre:

sudo aa-complain /etc/apparmor.d/*

eller i motsatt retning:

sudo aa-enforce /etc/apparmor.d/*

I mer ekstreme situasjoner kan det være lurt å deaktivere en bestemt profil midlertidigTil dette formålet finnes det aa-disable:

sudo aa-disable /etc/apparmor.d/usr.sbin.cupsd

Og hvis du trenger å granske alt et program gjør, selv det som vanligvis er tillatt, har du revisjonsmodus med aa-audit, som gjør alle overvåkede samtaler blir tatt opp uten å blokkere dem.

Når du endrer en profil manuelt eller vil laste den inn på nytt fra filen, kan du bruke apparmor_parser for å laste inn eller oppdatere bestemte profiler:

cat /etc/apparmor.d/profile.name | sudo apparmor_parser -a # cargar
cat /etc/apparmor.d/profile.name | sudo apparmor_parser -r # recargar

Og hvis du er interessert i å laste inn alle aktive profiler på systemet på nytt, kan du bruke init-skriptet (eller tilsvarende i systemd på moderne distribusjoner):

/etc/init.d/apparmor reload

Utforsk og forstå eksisterende profiler

Profilene som er lastet inn i kjernen er en refleksjon av filene som ligger i /etc/apparmor.d/For å liste opp innholdet i katalogen kan du gjøre følgende:

sudo ls /etc/apparmor.d

Du vil se navn som usr.sbin.sshd, usr.bin.manosv. Mange profiler av selve distribusjonen er gruppert i underkataloger som f.eks. /etc/apparmor.d/localdesignet for lokale variasjoner uten å endre hovedprofilen.

Hvis du er nysgjerrig og vil se reglene for en spesifikk profil, kan du gjøre følgende:

sudo cat /etc/apparmor.d/usr.sbin.sshd

Ved første øyekast kan syntaksen virke litt tørr, men mange linjer er forklart på en enkel måte som hjelper til med å forstå formålet med hver blokk. Uansett, hvis du ikke er komfortabel med syntaksen, er det best å ikke redigere disse filene manuelt og i stedet bruke de interaktive genererings- og justeringsverktøyene.

Oppdag prosesser uten profil og prioriter hva som skal begrenses

Ikke alle programmene på systemet ditt vil ha en tilknyttet AppArmor-profil. Faktisk vil ikke de fleste det. De du sannsynligvis låser først er vanligvis... de som er eksponert for nettverketenten fordi de åpner porter eller fordi de håndterer potensielt farlige data.

AppArmor inkluderer verktøyet aa-unconfined Slik viser du prosesser som lytter på nettverket, men som ikke har en profil:

aa-unconfined

Hvis du legger til parameteren --paranoidVerktøyet vil vise alle kjørende prosesser som opprettholder minst én aktiv nettverkstilkobling og er ikke begrenset:

aa-unconfined --paranoid

Denne listen fungerer som en veiledning for å hjelpe deg med å bestemme hvor du skal begynne. Du kan for eksempel oppdage at en webtjeneste, en proxy eller en databasedaemon... De opererer uten noen AppArmor-policysom er en invitasjon til å opprette en egen profil for dem.

Opprette nye profiler med aa-genprof og aa-logprof

Det kan være skremmende å lage en profil fra bunnen av, men AppArmor tilbyr verktøy i «læringsmodus» som forenkler oppgaven betraktelig. Ideen er enkel: Du kjører programmet i klagemodus, lar det gjøre jobben sin, og bygger deretter profilen fra loggene. generert av AppArmor.

Hovedbruken for dette er aa-genprof. Den grunnleggende syntaksen er:

sudo aa-genprof nombre_ejecutable

For eksempel, for å generere en profil for dhclient (DHCP-klient), kan du starte:

sudo aa-genprof dhclient

Den typiske arbeidsprosessen er omtrent slik: aa-genprof oppretter en innledende tom eller veldig åpen profilDen laster den inn i klagemodus og ber deg om det i en annen terminal, bruk programmet du vil profilere (i dette tilfellet, start eller tving frem anskaffelsen av en ny IP-adresse med dhclient).

Mens programmet kjører, logger AppArmor alle handlinger som ville blitt blokkert i håndhevingsmodus. Når du deretter går tilbake til aa-genprof og velger alternativet for å skanne hendelser, presenterer verktøyet deg en interaktiv liste over oppdagede brudd sammen med regelforslag.

Et eksempel på en første hendelse kan være utførelse av et hjelpeskript:

Perfil: /usr/sbin/dhclient
Ejecutar: /usr/sbin/dhclient-script
Severity: desconocido
(I)nherit / (C)hild / (P)rofile / (N)amed / (U)nconfined / (X) ix On / (D)eny / Abo(r)t / (F)inalizar

Herfra bestemmer du hva du skal gjøre med barneprosessene: start skriptet med samme profil (Arve), med en underprofil (Barn), med en dedikert profil (Profil/Navngitt), uten å begrense (Ubegrenset) eller forhindre utførelse (Nekt).

AppArmor administrerer også evnersom er spesielle kjernetillatelser som opprinnelig er reservert for root (for eksempel bruk av rå sokkeler, endring av systemtid osv.). Under profilering vil du se ting som:

Perfil: /usr/sbin/dhclient
Capability: net_raw
Severity: 8
(A)llow / (D)eny / (I)gnorar / Audi(t) / Abo(r)t / (F)inalizar

I hvert tilfelle bestemmer du om du vil tillate, nekte, ignorere (ikke opprette en regel), revidere eller avbryte. Det samme gjelder for filtilganghvor du vil bli vist spesifikke ruter, tilgangsmoduser (lese, skrive osv.) og mulige gjenbrukbare abstraksjoner.

Las abstraksjoner De er sett med felles regler pakket inn i gjenbrukbare filer (for eksempel <abstractions/nameservice> for alt som har med navneløsning å gjøre). I stedet for å legge til en løs regel for /etc/nsswitch.confDu kan inkludere abstraksjon og forenkle profilen.

På slutten av prosessen tilbyr aa-genprof å lagre de endrede profilene og laster dem automatisk inn på nytt i håndhevingsmodus, slik at programmet er begrenset av reglene du nettopp godkjenteHvis du oppdager ny atferd senere, kan du alltids kjøre den på nytt. aa-genprof eller, mer direkte, aa-logprof om de registrerte loggene.

Faktisk, aa-genprof er rett og slett et lite skript som bruker aa-logprof under.Den oppretter en tom profil, setter den i klagemodus, starter programmet og kaller deretter `aa-logprof` for å bygge profilen fra de loggede bruddene. Du kan bruke aa-logprof separat når du vil avgrense eksisterende profiler basert på nye hendelser.

Oppdage endringer i kode og kataloger ved hjelp av skall og hash

I tillegg til adgangskontrollfunksjoner er det i mange tilfeller av interesse oppdage om koden til et skript eller innholdet i en katalog har endret seg mellom henrettelser, for eksempel å avfyre ​​en full sikkerhetskopi bare når det er modifikasjoner, i stedet for å gjøre kontinuerlige trinnvise endringer.

Vi snakker ikke om sanntidsovervåking her (til det trenger du inotify og avledede verktøy), men snarere en engangssjekk: du kjører et skript som sjekker katalogstatusen, og hvis det oppdager endringer sammenlignet med sist, iverksetter det tiltak.

En veldig enkel tilnærming for en komplett katalog, uten unntak, innebærer å bruke statFølgende skjelett illustrerer ideen:

DIR_TO_CHECK='/dir/to/check'
OLD_STAT_FILE='/home/johndoe/old_stat.txt'

hvis; så
OLD_STAT=$(cat «$OLD_STAT_FIL»)
ellers
OLD_STAT="ingenting"
fi

NY_STAT=$(stat -t «$DIR_Å_SJEKK»)

hvis; så
echo 'Katalogen er endret. Gjør noe!'
# Her gjør du sikkerhetskopier, valideringer osv.
ekko «$NEW_STAT» > «$OLD_STAT_FIL»
fi

Logikken er veldig enkel: Du lagrer resultatet av `stat` i en fil, og ved neste kjøring sammenligner du det. med det nye resultatet. Hvis det er annerledes, antar du at noe har endret seg (størrelse, timings osv.) i katalogen. Denne teknikken er rask, men noe klumpete, og lar deg ikke enkelt ekskludere underbaner.

Hvis du vil sjekke en katalog, men ekskludere bestemte filer eller underkataloger (for eksempel en tmp/ lokale eller loggfiler), kan du sette sammen noe mer forseggjort ved å kombinere find, du, sort y sha1sum for å få et «fotavtrykk» av tilstanden til treet som interesserer deg.

Et eksempel på et skript kan være:

DIR_TO_CHECK='/dir/to/check'
PATH_TO_EXCLUDE="/dir/to/check/tmp*"
OLD_SUM_FILE='/home/johndoe/old_sum.txt'

hvis; så
GAMMEL_SUMMER=$(katt «$GAMMEL_SUMMER_FIL»)
ellers
OLD_SUM="ingenting"
fi

NEW_SUM=$(finn «$DIR_TO_CHECK»/* \! -sti «$PATH_TO_EXCLUDE» -print0 \
| xargs -0 du -b –time –exclude=»$PATH_TO_EXCLUDE» \
| sorter -k4,4 \
| sha1sum \
| awk '{skriv ut $1}')

hvis; så
echo «Katalog har endret seg. Gjør noe!»
ekko «$NEW_SUM» > «$OLD_SUM_FILE»
fi

Nøkkelen her ligger i linjen der beregningen gjøres. NY_SUMMER:

• find ... \! -path "$PATH_TO_EXCLUDE" -print0Alle filer i katalogen er oppført, bortsett fra de som samsvarer med mønsteret som skal ekskluderes. -print0 Den skiller navnene med et nulltegn for å unngå rot med mellomrom og rare tegn.
• xargs -0 du -b --time --exclude=...For hver fil som hentes, beregnes størrelsen i byte og tidsstempelinformasjon (avhengig av alternativer), og det bygges en liste der hver linje representerer et filsystemobjekt, og hvorfra Uønskede ruter er utelukket igjen.
• sort -k4,4Listen er ordnet i henhold til kolonnen som inneholder banen (vanligvis den fjerde), slik at rekkefølgen er deterministisk og enhver endring gjenspeiles i sekvensen.
• sha1sum | awk '{print $1}': er beregnet SHA1-sum av hele listen, som genererer et kort fotavtrykk som «representerer» hele statusen til katalogen (unntatt de som er ekskludert). En enkelt endring i størrelse, sti eller tidsstempel vil føre til at fotavtrykket endres.

På denne måten vil du vite hver gang du kjører skriptet om, mellom én kjøring og den neste, Noe relevant i treet har blitt endret, lagt til, fjernet eller omdøptOg det lar deg koble til andre handlinger: regenerere fullstendige sikkerhetskopier, kjøre integritetskontroller, laste inn tjenester på nytt, osv.

Hvordan passer AppArmor inn i deteksjon av skriptendringer?

Teknikkene beskrevet ovenfor lar deg allerede i seg selv oppdage endringer i koden til et skript eller i tilhørende ressurserMen hvis du kombinerer dette med AppArmor, kan du gå et skritt videre og få sikkerhetssystemet til å advare deg når et skript begynner å gjøre ting det ikke var ment å gjøre.

Tenk deg at du har et skript som bare skal lese et sett med filer og skrive til en bestemt katalog. Hvis du definerer en AppArmor-profil som bare tillater... leser til /opt/misdatos/ og skriver til /var/log/miscript/Ethvert forsøk på å få tilgang til andre nettsteder vil generere bruddshendelser i loggene (i klagemodus) eller vil bli blokkert fullstendig (i håndhevingsmodus).

Så hvis noen endrer skriptet (eller erstatter det med et skadelig et) for å slette filer i /etc/ eller sender data over nettverket, vil AppArmor fungere som et sikkerhetsnett. I tillegg vil gjennomgang av loggene med aa-logprof eller direkte i /var/log/syslog/journalctldet kan du oppdage unormal atferd som avslører endringer i koden eller utførelseslogikken.

En praktisk strategi er å kombinere begge tilnærmingene:

• På den ene siden, ved å bruke et lite hash-skript (basert på stat eller i summen av innholdet) for sjekk om skriptkoden og ressursene har endret seg siden siste anmeldelse.
• På den annen side, å plassere skriptet under en godt innstilt AppArmor-profil som begrenser dets oppførsel og Registrer ethvert forsøk på å avvike fra manuset.

Hvis begge systemene gir signaler (forskjellig hash og nye brudd i AppArmor), har du en ganske klar indikasjon på at noe har endret seg, og det er verdt å inspisere grundig.

Vanlige problemer knyttet til AppArmor og klargjøring av Linux VM

I skymiljøer som Azure sameksisterer AppArmor vanligvis med andre kritiske systemkomponenter, som for eksempel cloud-init og Azure Linux-agentenNår de blir opprettet virtuelle maskiner Med utgangspunkt i tilpassede avbildninger er det ikke uvanlig å støte på klargjøringsfeil som, selv om de ikke er direkte forårsaket av AppArmor, påvirker tjenester som kan være begrenset av profiler.

Et typisk tilfelle: når du distribuerer en virtuell maskin fra et image, forblir tilstanden i creating en god stund, og så går det videre til failed med meldinger som:

Provisioning failed. OS Provisioning for VM 'sentilo' did not finish in the allotted time...

O brønn:

OSProvisioningInternalError: The VM encountered an error during deployment...

For å diagnostisere disse problemene, tyr man til seriell konsolllogg Aktivering av Azure-oppstartsdiagnostikk lar deg se alt fra kommandolinjealternativer for kjernen til systemd-målsekvenser, kjøring av skyinitiering og Azure-agent, nettverkskonfigurasjon og nøkkelgenerering. SSHOsv

Disse loggene sjekker for eksempel om målet er oppnådd. "Nettverket er på nett", hvis cloud-init har fullført fasene sine (init-local, init, konfigurasjons- og sluttmoduler), hvis ISO-klargjøringsdiskene er riktig montert (de trenger UDF-driveren) eller hvis Azure-agenten markerer Finished provisioning.

Vanlige feil inkluderer:

• UDF-modul blokkert eller manglerKlargjøringsdisken er ikke montert, og cloud-init kan ikke lese metadataene, noe som resulterer i meldingen «Ingen Azure-metadata funnet».
• Unicode-problemer i VM-etiketter eller passord, spesielt med eldre versjoner av cloud-init som ikke håndterer ikke-ASCII-tegn godt.
• Montering av /var/tmp med noexecsom hindrer cloud-init i å kjøre dhclient når den kopieres til den banen i versjoner før 20.3.

Alt dette kan løses ved å oppdatere til nyere versjoner av cloud-init, korrigere monteringsparametrene og sørge for at nødvendige kjernemoduler (som UDF-er) ikke er låst i /etc/modprobe.d/Hvis du også bruker AppArmor på disse virtuelle maskinene, er det verdt å sjekke det. unngå altfor restriktive profiler påvirker komponenter som cloud-init, dhclient, systemd-networkd eller Azure-agenten, da de kan forstyrre klargjøringen.

Deaktiver AppArmor fullstendig (når det ikke finnes noe annet alternativ)

Selv om det anbefales å justere profiler og moduser i stedet for å velge den enkle utveien, kan det i svært spesifikke tilfeller være nødvendig deaktiver AppArmor fullstendigFor eksempel for å utelukke at det forårsaker et esoterisk problem i et testmiljø.

sudo /etc/init.d/apparmor stop
sudo update-rc.d -f apparmor remove

Og hvis du vil aktivere den på nytt senere, kan du bare starte den og registrere den på nytt på standard oppstartsnivåer:

sudo /etc/init.d/apparmor start
sudo update-rc.d apparmor defaults

Husk at deaktivering av AppArmor fjerner hele laget med MAC-beskyttelse det gir, og gjør prosesser sårbare igjen. begrenset kun av tradisjonelle DAC-tillatelserDet mest fornuftige å gjøre er å bruke dette målet kun til spesifikke diagnostiske formål, og når problemet er identifisert, aktivere det på nytt og justere de motstridende profilene.

Når det er sagt, er det mulig å kombinere bruken av AppArmor for å begrense oppførselen til skript og tjenester med enkle hashing- og sammenligningsteknikker uten for mye komplikasjon. oppdage endringer i koden og nøkkelkatalogene til et Linux-systemDette gir et ekstra lag med trygghet når du administrerer maskiner i produksjon eller i skyen, og du vil ikke at noe skal flytte seg uten din viten.