Root i en terminal, afvist under SELinux: hvorfor hooket fejler

Du kører up-scriptet som root, det fuldføres, og det samme script fejler, når tjenesten kalder det. Intet ved filens rettigheder er ændret, så det næste naturlige skridt er at løsne dem igen, hvilket ikke løser noget. På en SELinux-vært er den afgørende faktor ofte ikke, hvem processen er, men hvilket domæne den kører i, og root inde i et indskrænket domæne er stadig indskrænket.

Samme kommando, to forskellige sikkerhedsdomæner

Typehåndhævelse vurderer kildedomænet, mållabelen og den anmodede handling samlet. Din terminalsession kører i et ubegrænset eller administrativt domæne, og dæmonen kører i det domæne, dens unit er tildelt. Identiske kommandoer giver derfor forskellige afgørelser, og forskellen er tilsigtet snarere end en fejl i politikken.

Derfor er sammenligningen af de to kørsler kun nyttig, hvis du sammenligner deres kontekster. Kør den samme kommando fra skallen og fra hooket, og skallens version beviser, at binæren findes, og at argumenterne er rigtige; den beviser intet om, hvorvidt tjenesten må køre den. Kør den begge veje og sammenlign domænerne, ikke kun exitkoderne. Netop den sammenligning gør en vag tilladelsesklage til et konkret spørgsmål om ét domæne og én label.

Den klassiske form for denne fejl er en hjælper, der kalder et eksternt værktøj. Selve hooket kan være tilladt, mens det værktøj, det kalder, har en label, som tjenestedomænet ikke må køre, eller skriver til en mappe, hvis label forbyder det.

Læs AVC-posten ved siden af hookfejlen

En AVC-afvisning navngiver de felter, der afgør sagen: processens kildekontekst, objektets målkontekst, objektklassen og den specifikke tilladelse, der blev afvist. Læs alle fire, før du danner en teori, fordi en afvisning på execute og en afvisning på write har helt forskellige reparationer.

ausearch -m AVC,USER_AVC -ts recent
ls -Z /usr/local/sbin/vpn-up.sh
ps -eZ | grep openvpn

Kildekonteksten bør svare til det domæne, tjenesten faktisk kører i, og målkonteksten bør svare til labelen på den fil eller mappe, handlingen berørte. Hvis en af dem ikke passer med den fejl, du jagter, læser du en anden hændelse.

Notér politikversionen og den præcise sti til den kørende fil ved siden af posten. Et domænenavn, der optræder i én distributions politik, er bevis om den installation, ikke en garanti for, at et andet build leverer de samme regler. Denne kontekst er det, der lader andre genskabe din konklusion på deres egen vært. Uden den læses posten som en anekdote snarere end bevis.

Label, konfiguration eller politik: tre reparationer

Den første reparation er en label, der ikke passer til filens installerede placering. Et script, der er kopieret på plads med cp eller skrevet af en editor, kan bære en standardlabel, som tjenestedomænet ikke kan bruge, og gendannelse af den forventede kontekst løser det uden at røre politikken.

Den anden er konfiguration. Distributionen tilbyder måske en understøttet måde at køre handlingen på, en dokumenteret mappe til hjælperen eller en opdateret politikpakke, der allerede tillader det. At ændre dit layout til det understøttede er billigere end at skrive politik og overlever opdateringer.

Den tredje er en reelt manglende regel, og den bør være den sidste udvej. Generér en kandidat med revisionsværktøjerne, læs, hvad den faktisk tillader, indsnævr den til den handling og det domæne, du observerede, og få en anden til at gennemgå den, før den kommer i nærheden af produktion.

Hvorfor et gammelt allow-modul ikke er svaret

Søgeresultater for denne fejl er fyldt med færdige moduler, ofte til et værktøj, som hooket ikke længere kalder. Installation af ét giver tilladelser, der måske intet har at gøre med din afvisning, og det lader den egentlige uoverensstemmelse blive på plads, mens det tilføjer et permanent hul.

Det skjuler også den næste fejl. Et modul, der tillader en bred klasse af handlinger, får denne fejl til at forsvinde og gør den næste til noget langt sværere at henføre. At fjerne modulet senere er også en ændring, ingen vil planlægge, så genvejen har tendens til at blive permanent.

Den disciplinerede sammenligning er mellem den afvisning, du kan læse, og den ændring, du foreslår. Red Hats vejledning i fejlfinding af SELinux sætter label- og konfigurationskontroller foran genereret politik netop af denne grund. Hvis der ikke er en tilsvarende afvisning i posten, er SELinux sandsynligvis ikke dit problem, og problemer med sti, sandbox eller tilladelser er stadig åbne.