Hvorfor flytning af et VPN-certifikat ødelægger dets SELinux-label

Certifikater kan ligge i den rigtige mappe med en læsbar tilstand og root-ejerskab, og tjenesten kan alligevel rapportere, at den ikke kan åbne filen. På et SELinux-system peger den kombination på én bestemt mekanisme frem for på rettigheder. Labelen rejste med filen, fordi en omdøbning ikke opretter et nyt objekt. Inoden beholdt den sikkerhedskontekst, den havde på den gamle sti, og politikken for den nye sti fik aldrig chancen for at tildele sin egen.

Hvad en omdøbning egentlig gør ved en label

En fil bærer sin SELinux-kontekst som attributdata knyttet til inoden. Omdøbning inden for samme filsystem ændrer mappeposten og intet andet, hvilket er hurtigt og atomart, og grunden til at konteksten overlever flytningen. Ingen politik bliver spurgt, ingen standard bliver anvendt, og ingen advarsel bliver udskrevet.

Kopiering opfører sig anderledes. En kopi opretter en ny inode i målmappen, og politikken tildeler en kontekst ud fra den mappes type, så et kopieret certifikat ender normalt med den rigtige label, mens et flyttet forbliver forkert. Den ene forskel forklarer det meste af forvirringen i denne type sag.

Flytninger mellem filsystemer falder tilbage til kopieringssemantik, så den samme kommando kan opføre sig forskelligt på to maskiner afhængigt af, om /etc bor på sin egen diskenhed. Kontroller det, før du konkluderer, at værktøjet er upålideligt. Et blik på monteringstabellen fortæller dig, hvilken slags flytning du udførte.

Læs den aktuelle label op imod den forventede

Tre skrivebeskyttede kommandoer besvarer spørgsmålet uden at ændre noget. Den første viser, hvad filen har nu, den anden rapporterer, hvad politikken forventer for netop den sti, og den tredje lister hver fil under mappen, hvis label afviger.

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

Prøvekørslen er den, man skal stole på, fordi den navngiver hver fil, hvis kontekst afviger fra politikken, og stadig lader systemet være urørt. Hvis certifikatet optræder på den liste, har du fundet uoverensstemmelsen mellem, hvad stien betyder, og hvad filen hævder. Hvis det ikke optræder, er labelen allerede det, politikken vil have, og din tid hører til et andet sted.

Korrelér derefter forskellen med en faktisk afvisning. En uoverensstemmelse er bevis på en forkert label, ikke bevis for at tjenesten fejlede på grund af den, og en rettelse anvendt uden en tilsvarende afvisning i loggen er et gæt med ekstra trin.

Gendan mappingen i stedet for at opfinde en undtagelse

For en standardplacering mapper politikken allerede stien, så restorecon anvender den, og arbejdet er gjort. Hold omfanget til den mappe, du reparerer; at relabe hele filsystemet er langsomt, forstyrrende, og det begraver den oprindelige fejl under en meget stor ændring.

For en tilpasset mappe betyder rækkefølgen noget, og at vende den giver en kommando, der rapporterer succes, mens intet ændres. Mappingen hører i politikken, relabningen hører til sidst, og prøvekørslen hører før begge. At springe den sidste del over er, hvordan en sti, der aldrig var forkert, alligevel bliver relabelt.

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

restorecon anvender en mapping; den kan ikke opfinde en. Hvis ingen regel beskriver stien, er der intet at gendanne fra, og derfor skal den vedvarende mapping findes før relabningen. Notér, hvilken konfiguration der ejer den mapping, for ellers genskaber en senere flytning, en pakkeopdatering eller en relabning fejlen, og den næste person starter fra nul.

Hvorfor chcon ikke er løsningen

chcon skriver en kontekst direkte på filen. Det virker med det samme, og det er den mindst holdbare mulighed, der findes, fordi en relabning af filsystemet anvender politikken igen og kasserer manuelle ændringer uden at spørge. Filen ser repareret ud, og reparationen har en udløbsdato, som ingen har skrevet ned. Det, du i stedet vil have, er en regel, der beskriver stien, så hver fil, der ankommer dertil, automatisk får samme behandling.

Værre, det lærer den forkerte lektie: den underliggende mapping mangler stadig, så fejlen vender tilbage uger senere uden en oplagt udløser og uden erindring om omvejen. Brug kun chcon som et midlertidigt eksperiment til at bekræfte en hypotese, og erstat det derefter med en mapping, der overlever den næste relabning, og kontroller, at erstatningen faktisk er på plads.

Når labelen er rigtig, og adgangen stadig fejler

Start med de overordnede mapper. Gennemgangstilladelse kontrolleres på hver komponent i stien, så et korrekt labelt certifikat i en mappe, som tjenesten ikke kan komme ind i, stadig er ulæseligt. Både SELinux og almindelig tilladelse skal tillade hvert trin, og at rette det ene retter ikke det andet.

Kontroller derefter procesidentitet og tjenestens egen sandkasse. En enhed med en restriktiv sandkasse kan nægte adgang til en fil, som politikken gerne ville tillade, og ud fra loglinjen ser de to årsager ens ud. Bekræft, hvilken proces der faktisk spørger, ikke hvilken du antager spørger.

Husk, at dontaudit-regler kan undertrykke afvisningsmeddelelser, så en tom revisionslog er svagt bevis frem for bevis. Hvis politikken ser rigtig ud, og adgangen stadig fejler, så undersøg, før du genererer et bredt tilladelsesmodul, og deaktiver ikke SELinux for at få symptomet til at forsvinde. Begge genveje giver et system, der ser ud til at virke, og en sikkerhedsposition, som ingen kan beskrive. En kort undersøgelse slår begge.