Rettigheter i Linux svarer på spørsmålet «hvem får lese denne filen». AppArmor stiller et annet: «hva får dette programmet i det hele tatt lov til å gjøre». Forskjellen viser seg ved et innbrudd. Et webskall kjøres med webserverbrukerens rettigheter og arver alle privilegiene dens — altså leseadgang til en god del av systemet. En AppArmor-profil begrenser prosessen til listen over det den trenger til arbeidet sitt, og et forsøk på å lese /etc/shadow eller starte /bin/bash ender med avslag, uansett brukerens rettigheter.

Hva som allerede er påslått

sudo aa-status

Utdataene svarer på tre spørsmål: hvor mange profiler som er lastet inn, hvor mange av dem som kjører i enforce og complain, og hvilke prosesser som kjører helt uten profil. I et typisk Ubuntu blir det noen titalls profiler, men nesten alle for hjelpeprogrammer av typen man og tcpdump. De sentrale tjenestene — nginx, Apache, PHP-FPM — mangler som regel i listen over begrensede.

Tre modi må holdes fra hverandre:

  • enforce — reglene gjelder, alt overflødig er forbudt;
  • complain — brudd registreres bare, ingenting blokkeres. Modusen for innkjøring;
  • unconfined — ingen profil finnes, programmet kjører uten begrensninger.

Den nyttigste delen av aa-status er den siste: prosesser som lytter på nettverket og ikke begrenses av noe. Det er listen å begynne med.

Verktøyene

sudo apt install apparmor-utils

Uten den pakken finnes kommandoene aa-complain, aa-enforce og aa-logprof ikke i systemet, selv om AppArmor selv virker.

Hvordan du slår på en profil uten å stanse tjenesten

Rekkefølgen er avgjørende. En profil som settes rett i enforce, vil med stor sannsynlighet forby tjenesten noe den trenger, og da slutter den å virke — som regel ikke straks, men ved en sjelden operasjon som å sende en fil eller et brev.

Riktig rekkefølge:

sudo aa-complain /etc/apparmor.d/usr.sbin.nginx

En uke i den modusen, inkludert alle uvanlige forløp: sikkerhetskopiering, oppdatering, opplasting av store filer. Deretter en gjennomgang av det som har samlet seg:

sudo aa-logprof

Kommandoen går gjennom registrerte brudd og spør ved hvert enkelt om det skal tillates. Her trengs oppmerksomhet: tillat det som virkelig hører til tjenestens arbeid, og ikke alt på rad — ellers blir resultatet en profil som tillater alt, og poenget forsvinner.

Og først deretter:

sudo aa-enforce /etc/apparmor.d/usr.sbin.nginx

Hvor du ser avslagene

Alle brudd havner i kjerneloggen:

sudo journalctl -k | grep -i apparmor
sudo grep 'apparmor="DENIED"' /var/log/audit/audit.log

Den andre filen finnes dersom auditd er installert — og da er oppføringene betydelig fyldigere. I en avslagsoppføring ses profilnavnet, den forespurte operasjonen og stien det ble spurt etter; det holder for å avgjøre om profilen skal rettes, eller om man skal glede seg over at den virket.

Legg særlig merke til symptomet: tjenesten oppfører seg underlig — leser ikke konfigurasjonen, skriver ikke til en katalog, åpner ikke en socket — og har i sine egne logger feilen «tilgang nektet» til tross for helt korrekte rettigheter. Det er nesten alltid AppArmor, og det første man gjør, er å se i kjerneloggen.

Et praktisk tiltak, ikke et teoretisk

En profil for PHP-FPM eller nginx lønner seg på en konkret måte. Med prosessen begrenset kan et webskall som har havnet på nettstedet, verken lese systemfiler, starte et skall eller skrive noe sted utenfor de tillatte katalogene. Et innbrudd på nettstedet forblir et innbrudd på nettstedet i stedet for å bli tilgang til hele maskinen — og nettopp den overgangen utgjør den vesentlige delen av skaden.

En fornuftig innføringsrekkefølge: først en profil for det som vender mot internett (webserveren, PHP-FPM), så for databasene, deretter etter behov. Alt trenger ikke slås på på én gang, og noe ferdig universelt sett finnes ikke: profilen avhenger av hvor filene dine ligger.

Hva du kontrollerer jevnlig

Profiler faller tilbake til ubegrenset oftere enn man tror: en pakkeoppdatering kan bytte ut profilfilen, manuell feilsøking etterlater tjenesten i complain, og en ny tjeneste kommer helt uten profil. To tall er nyttige: hvor mange profiler som er i enforce, og hvor mange nettverksprosesser som kjører uten begrensninger. En endring i det ene eller det andre er verdt oppmerksomhet. Hvordan det ser ut samlet på én side, viser demonstrasjonen nedenfor.