Hvorfor flytting av et VPN-sertifikat ødelegger SELinux-etiketten

Sertifikater kan ligge i riktig mappe med lesbar modus og root-eierskap, og tjenesten kan likevel rapportere at den ikke kan åpne filen. På et SELinux-system peker den kombinasjonen på én bestemt mekanisme og ikke på rettigheter. Etiketten reiste med filen, fordi en omdøping ikke oppretter et nytt objekt. Inoden beholdt sikkerhetskonteksten den hadde på den gamle stien, og policyen for den nye stien fikk aldri sjansen til å tildele sin egen.

Hva en omdøping faktisk gjør med en etikett

En fil bærer SELinux-konteksten sin som attributtdata knyttet til inoden. Omdøping innenfor ett filsystem endrer mappeposten og ingenting annet, noe som er raskt og atomisk, og grunnen til at konteksten overlever flyttingen. Ingen policy blir spurt, ingen standardverdi blir brukt, og ingen advarsel blir skrevet ut.

Kopiering oppfører seg annerledes. En kopi oppretter en ny inode i målmappen, og policyen tildeler en kontekst ut fra den mappens type, så et kopiert sertifikat ender vanligvis med riktig etikett, mens et flyttet forblir feil. Nettopp denne ene forskjellen forklarer det meste av forvirringen i denne typen sak.

Flyttinger mellom filsystemer faller tilbake til kopieringssemantikk, så samme kommando kan oppføre seg ulikt på to maskiner avhengig av om /etc bor på sitt eget volum. Kontroller det før du konkluderer med at verktøyet er upålitelig. Ett blikk på monteringstabellen forteller deg hva slags flytting du utførte.

Les den gjeldende etiketten mot den forventede

Tre skrivebeskyttede kommandoer svarer på spørsmålet uten å endre noe. Den første viser hva filen har nå, den andre rapporterer hva policyen forventer for nettopp den stien, og den tredje lister opp hver fil under mappen der etiketten avviker.

ls -lZ /etc/openvpn/client/office-ca.crt
matchpathcon /etc/openvpn/client/office-ca.crt
restorecon -Rn -v /etc/openvpn/client

Det er tørrkjøringen man skal stole på, fordi den navngir hver fil der konteksten avviker fra policyen og likevel lar systemet være urørt. Hvis sertifikatet dukker opp på den listen, har du funnet avviket mellom hva stien betyr og hva filen hevder. Hvis det ikke dukker opp, er etiketten allerede det policyen vil ha, og tiden din hører til et annet sted.

Korrelér deretter forskjellen med en faktisk avvisning. Et avvik er bevis på feil etikett, ikke bevis for at tjenesten feilet på grunn av det, og en rettelse brukt uten en tilsvarende avvisning i loggen er en gjetning med ekstra trinn.

Gjenopprett tilordningen i stedet for å finne opp et unntak

For en standardplassering tilordner policyen allerede stien, så restorecon bruker den, og arbeidet er gjort. Hold omfanget til mappen du reparerer; å merke hele filsystemet på nytt er tregt, forstyrrende, og det begraver den opprinnelige feilen under en svært stor endring.

For en tilpasset mappe betyr rekkefølgen noe, og å snu den gir en kommando som rapporterer suksess mens ingenting endres. Tilordningen hører i policyen, nymerkingen hører til slutten, og tørrkjøringen hører før begge. Å hoppe over den siste delen er hvordan en sti som aldri var feil likevel blir nymerket.

semanage fcontext -a -t openvpn_etc_t '/etc/openvpn/custom(/.*)?'
restorecon -Rv /etc/openvpn/custom

restorecon bruker en tilordning; det kan ikke finne opp en. Hvis ingen regel beskriver stien, er det ingenting å gjenopprette fra, og derfor må den vedvarende tilordningen finnes før nymerkingen. Noter hvilken konfigurasjon som eier den tilordningen, for ellers gjenoppretter en senere flytting, en pakkeoppdatering eller en nymerking feilen, og neste person starter på null.

Hvorfor chcon ikke er løsningen

chcon skriver en kontekst direkte på filen. Det virker umiddelbart, og det er det minst varige alternativet som finnes, fordi en nymerking av filsystemet bruker policyen på nytt og kaster manuelle endringer uten å spørre. Filen ser reparert ut, og reparasjonen har en utløpsdato som ingen har skrevet ned. Det du i stedet vil ha, er en regel som beskriver stien, slik at hver fil som ankommer dit automatisk får samme behandling.

Verre, det lærer feil lekse: den underliggende tilordningen mangler fortsatt, så feilen kommer tilbake uker senere uten en åpenbar utløser og uten minne om omveien. Bruk chcon bare som et midlertidig eksperiment for å bekrefte en hypotese, og bytt det deretter ut med en tilordning som overlever den neste nymerkingen, og kontroller at erstatningen faktisk er på plass.

Når etiketten er riktig og tilgangen likevel feiler

Start med de overordnede mappene. Gjennomgangstillatelse kontrolleres på hver komponent i stien, så et riktig merket sertifikat i en mappe tjenesten ikke kommer inn i, er fortsatt uleselig. Både SELinux og vanlig tillatelse må tillate hvert trinn, og å rette det ene retter ikke det andre.

Kontroller deretter prosessidentitet og tjenestens egen sandkasse. En enhet med en restriktiv sandkasse kan nekte tilgang til en fil som policyen gjerne ville tillate, og fra logglinjen ser de to årsakene identiske ut. Bekreft hvilken prosess som faktisk spør, ikke hvilken du antar spør.

Husk at dontaudit-regler kan undertrykke avvisningsmeldinger, så en tom revisjonslogg er svakt bevis og ikke bevis. Hvis policyen ser riktig ut og tilgangen likevel feiler, undersøk før du genererer en bred tillatelsesmodul, og ikke deaktiver SELinux for å få symptomet til å forsvinne. Begge snarveiene gir et system som ser ut til å virke og en sikkerhetsholdning ingen kan beskrive. En kort undersøkelse slår begge.