Kvifor flytting av eit VPN-sertifikat øydelegg SELinux-etiketten

Sertifikat kan liggje i rett mappe med lesbar modus og root-eige, og tenesta kan likevel rapportere at ho ikkje kan opne fila. På eit SELinux-system peikar den kombinasjonen på éin bestemt mekanisme og ikkje på rettar. Etiketten reiste med fila, fordi ei omdøypling ikkje lagar eit nytt objekt. Inoden behaldt tryggleikskonteksten han hadde på den gamle stien, og policyen for den nye stien fekk aldri sjansen til å tildele sin eigen.

Kva ei omdøypling faktisk gjer med ein etikett

Ei fil ber SELinux-konteksten sin som attributtdata knytte til inoden. Omdøypling innanfor eitt filsystem endrar mappeposten og ingenting anna, noko som er raskt og atomisk, og grunnen til at konteksten overlever flyttinga. Ingen policy vert spurd, ingen standardverdi vert brukt, og inga åtvaring vert skriven ut.

Kopiering oppfører seg annleis. Ei kopi lagar ein ny inode i målmappa, og policyen tildeler ein kontekst ut frå typen til den mappa, så eit kopiert sertifikat endar vanlegvis med rett etikett, medan eit flytta blir verande feil. Nettopp denne eine skilnaden forklarer det meste av forvirringa i denne typen sak.

Flyttingar mellom filsystem fell tilbake på kopieringssemantikk, så same kommando kan oppføre seg ulikt på to maskinar avhengig av om /etc bur på sitt eige volum. Kontroller det før du konkluderer med at verktøyet er upåliteleg. Eitt blikk på monteringstabellen fortel deg kva slag flytting du utførte.

Les den gjeldande etiketten mot den forventa

Tre skriveverna kommandoar svarar på spørsmålet utan å endre noko. Den første viser kva fila har no, den andre rapporterer kva policyen forventar for nettopp den stien, og den tredje listar opp kvar fil under mappa der etiketten avvik.

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

Det er tørrkøyringa ein skal stole på, fordi ho namngir kvar fil der konteksten avvik frå policyen og likevel lèt systemet vere urørt. Viss sertifikatet dukkar opp på den lista, har du funne avviket mellom kva stien tyder og kva fila hevdar. Viss det ikkje dukkar opp, er etiketten allereie det policyen vil ha, og tida di høyrer til ein annan stad.

Korrelér deretter skilnaden med ei faktisk avvising. Eit avvik er prov på feil etikett, ikkje prov for at tenesta feila på grunn av det, og ei retting brukt utan ei tilsvarande avvising i loggen er ei gjetting med ekstra steg.

Gjenopprett tilordninga i staden for å finne opp eit unntak

For ein standardplassering tilordnar policyen allereie stien, så restorecon brukar han, og arbeidet er gjort. Hald omfanget til mappa du reparerer; å merke heile filsystemet på nytt er tregt, forstyrrande, og det grev ned den opphavlege feilen under ei svært stor endring.

For ei tilpassa mappe betyr rekkjefølgja noko, og å snu ho gjev ein kommando som rapporterer suksess medan ingenting endrar seg. Tilordninga høyrer i policyen, nymerkinga høyrer til slutten, og tørrkøyringa høyrer før båe. Å hoppe over den siste delen er korleis ein sti som aldri var feil likevel vert nymerkt.

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

restorecon brukar ei tilordning; det kan ikkje finne opp ei. Viss ingen regel skildrar stien, er det ingenting å gjenopprette frå, og difor må den varige tilordninga finnast før nymerkinga. Noter kva konfigurasjon som eig den tilordninga, for elles gjenopprettar ei seinare flytting, ein pakkeoppdatering eller ei nymerking feilen, og neste person startar på null.

Kvifor chcon ikkje er løysinga

chcon skriv ein kontekst direkte på fila. Det verkar med ein gong, og det er det minst varige alternativet som finst, fordi ei nymerking av filsystemet brukar policyen på nytt og kastar manuelle endringar utan å spørje. Fila ser reparert ut, og reparasjonen har ein utløpsdato som ingen har skrive ned. Det du i staden vil ha, er ein regel som skildrar stien, slik at kvar fil som kjem dit automatisk får same handsaming.

Verre, det lærer feil lekse: den underliggjande tilordninga manglar framleis, så feilen kjem tilbake veker seinare utan ein openber utløysar og utan minne om omvegen. Bruk chcon berre som eit mellombels eksperiment for å stadfeste ein hypotese, og byt det deretter ut med ei tilordning som overlever den neste nymerkinga, og kontroller at erstatninga faktisk er på plass.

Når etiketten er rett og tilgangen likevel feilar

Start med dei overordna mappene. Gjennomgangsløyve vert kontrollert på kvar komponent i stien, så eit rett merkt sertifikat i ei mappe tenesta ikkje kjem inn i, er framleis uleseleg. Både SELinux og vanleg løyve må tillate kvart steg, og å rette det eine rettar ikkje det andre.

Kontroller deretter prosessidentitet og tenesta si eiga sandkasse. Ei eining med ein restriktiv sandkasse kan nekte tilgang til ei fil som policyen gjerne ville tillate, og frå logglinja ser dei to årsakene identiske ut. Stadfest kva prosess som faktisk spør, ikkje kva du går ut frå spør.

Hugs at dontaudit-reglar kan undertrykkje avvisingsmeldingar, så ein tom revisjonslogg er svakt prov og ikkje prov. Viss policyen ser rett ut og tilgangen likevel feilar, gransk før du genererer ein brei løyvesmodul, og ikkje deaktiver SELinux for å få symptomet til å forsvinne. Båe snarvegane gjev eit system som ser ut til å verke og ei tryggleikshaldning ingen kan skildre. Ei kort gransking slår båe.