Varför flytt av ett VPN-certifikat bryter dess SELinux-etikett

Certifikat kan ligga i rätt katalog med läsbart läge och root-ägande, och tjänsten kan ändå rapportera att den inte kan öppna filen. På ett SELinux-system pekar den kombinationen på en viss mekanism och inte på behörigheter. Etiketten följde med filen, eftersom en namnändring inte skapar ett nytt objekt. Inoden behöll den säkerhetskontext den hade på den gamla sökvägen, och policyn för den nya sökvägen fick aldrig chansen att tilldela sin egen.

Vad en namnändring faktiskt gör med en etikett

En fil bär sin SELinux-kontext som attributdata kopplade till inoden. Namnändring inom ett filsystem ändrar katalogposten och inget annat, vilket är snabbt och atomärt, och skälet till att kontexten överlever flytten. Ingen policy tillfrågas, inget standardvärde tillämpas och ingen varning skrivs ut.

Kopiering beter sig annorlunda. En kopia skapar en ny inode i målkatalogen, och policyn tilldelar en kontext utifrån den katalogens typ, så ett kopierat certifikat får oftast rätt etikett medan ett flyttat förblir fel. Just den enda skillnaden förklarar det mesta av förvirringen i den här typen av ärende.

Flyttar mellan filsystem faller tillbaka på kopieringssemantik, så samma kommando kan bete sig olika på två maskiner beroende på om /etc ligger på en egen volym. Kontrollera det innan du drar slutsatsen att verktyget är opålitligt. En blick på monteringstabellen säger vilken sorts flytt du utförde.

Läs den aktuella etiketten mot den förväntade

Tre skrivskyddade kommandon svarar på frågan utan att ändra något. Det första visar vad filen har nu, det andra rapporterar vad policyn förväntar sig för just den sökvägen, och det tredje listar varje fil under katalogen vars etikett skiljer sig.

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

Det är torrkörningen man ska lita på, eftersom den namnger varje fil vars kontext avviker från policyn och ändå lämnar systemet orört. Om certifikatet dyker upp på listan har du hittat avvikelsen mellan vad sökvägen betyder och vad filen påstår. Om det inte dyker upp är etiketten redan vad policyn vill ha och din tid hör hemma någon annanstans.

Korrelera sedan skillnaden med en faktisk nekad åtkomst. En avvikelse är bevis på fel etikett, inte bevis för att tjänsten misslyckades på grund av den, och en rättelse som tillämpas utan en motsvarande nekad åtkomst i loggen är en gissning med extra steg.

Återställ mappningen i stället för att hitta på ett undantag

För en standardplats mappar policyn redan sökvägen, så restorecon tillämpar den och arbetet är klart. Håll omfånget till katalogen du reparerar; att märka om hela filsystemet är långsamt, störande och begraver det ursprungliga misstaget under en mycket stor ändring.

För en anpassad katalog spelar ordningen roll, och att vända på den ger ett kommando som rapporterar framgång utan att ändra något. Mappningen hör till policyn, ommärkningen hör till slutet och torrkörningen hör före båda. Att hoppa över den sista delen är hur en sökväg som aldrig var fel ändå blir ommärkt.

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

restorecon tillämpar en mappning; det kan inte hitta på en. Om ingen regel beskriver sökvägen finns inget att återställa från, och därför måste den beständiga mappningen finnas före ommärkningen. Anteckna vilken konfiguration som äger mappningen, för annars återskapar en senare flytt, en paketuppdatering eller en ommärkning felet och nästa person börjar från noll.

Varför chcon inte är lösningen

chcon skriver en kontext direkt på filen. Det verkar omedelbart och är det minst varaktiga alternativ som finns, eftersom en ommärkning av filsystemet tillämpar policyn igen och kastar manuella ändringar utan att fråga. Filen ser reparerad ut och reparationen har ett utgångsdatum som ingen skrev ned. Det du i stället vill ha är en regel som beskriver sökvägen, så att varje fil som kommer dit automatiskt får samma behandling.

Värre, det lär ut fel läxa: den underliggande mappningen saknas fortfarande, så felet återkommer veckor senare utan uppenbar utlösare och utan minne av kringgåendet. Använd chcon bara som ett tillfälligt experiment för att bekräfta en hypotes, byt sedan ut det mot en mappning som överlever nästa ommärkning och kontrollera att ersättningen verkligen är på plats.

När etiketten är rätt och åtkomsten ändå misslyckas

Börja med de överordnade katalogerna. Genomgångsbehörighet kontrolleras på varje komponent i sökvägen, så ett korrekt märkt certifikat i en katalog som tjänsten inte kan komma in i förblir oläsbart. Både SELinux och den vanliga behörigheten måste tillåta varje steg, och att rätta det ena rättar inte det andra.

Kontrollera sedan processidentiteten och tjänstens egen sandlåda. En enhet med en restriktiv sandlåda kan neka åtkomst till en fil som policyn gärna skulle tillåta, och från loggrader ser de två orsakerna identiska ut. Bekräfta vilken process som faktiskt frågar, inte vilken du antar frågar.

Kom ihåg att dontaudit-regler kan dämpa nekade meddelanden, så en tom granskningslogg är svagt bevis och inte bevis. Om policyn ser rätt ut och åtkomsten ändå misslyckas, undersök innan du genererar en bred tillåtelsemodul, och inaktivera inte SELinux för att få symtomet att försvinna. Båda genvägarna ger ett system som verkar fungera och en säkerhetshållning som ingen kan beskriva. En kort undersökning är bättre än båda.