Hvorfor flytting av et VPN-sertifikat bryter SELinux-etiketten

Sertifikater kan ligge i korrekt mappe med lesbar modus og root-eierskap, og tjenesten kan likevel melde 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 egentlig 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 hurtig 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 anderledes. En kopi oppretter en ny inode i målmappen, og policyen tildeler en kontekst ut fra den mappens type, slik at et kopiert sertifikat vanligvis ender 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. Sjekk det før du konkluderer med at verktøyet er upålitelig. Et blikk på monteringstabellen forteller deg hvilken type flytting du utførte.

Les den gjeldende etiketten mot den forventede

Tre skrivebeskyttede kommandoer besvarer 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 en skal stole på, fordi den navngir hver fil der konteksten avviker fra policyen og likevel lar systemet være urørt. Dersom 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 så 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 framfor å finne opp et unntak

For en standardplassering tilordner policyen allerede stien, så restorecon bruker den, og arbeidet er gjort. Begrens omfanget til mappen du reparerer; å merke hele filsystemet på nytt er tregt, forstyrrende, og det begraver den opphavelige 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. Notér 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 øyeblikkelig, 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 ut som den er reparert, 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 kun 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 korrekt og tilgangen likevel feiler

Begynn 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 vanlige tillatelser må tillate hvert trinn, og å rette det ene retter ikke det andre.

Sjekk 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. Fastslå 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 er bedre enn begge.