Stapla inte systemd-härdning ovanpå OpenVPN:s user-nedgång

Två hopklistrade recept med minsta möjliga rättigheter ger inte en strängare driftsättning. Den ena modellen låter demonen starta med rättigheter och falla ned till ett konto utan rättigheter efter initieringen; den andra låter tjänstehanteraren starta den under en begränsad identitet redan från första instruktionen. Var för sig fungerar de, och kombinationen ger ofta en tjänst som inte klarar någon av de två uppgifterna ordentligt. Resten går igenom beslutet i ordning.

Två modeller, en ägare av bytet

Den första modellen tillhör demonen. Communityversionen av OpenVPN har alternativen user och group, som byter identitet efter att tunneln och nycklarna är uppsatta, och persist-key plus persist-tun håller dessa resurser användbara efteråt.

Den andra modellen tillhör tjänstehanteraren. En systemd-inställning User= eller Group= avgör vilken identitet processen startar under, och kapabilitetsdirektiv avgör vad den får hålla. Valet mellan modellerna är en paketeringsfråga innan det är en säkerhetsfråga, och paketansvarig har redan svarat på den. Din uppgift är att hitta det svaret i stället för att hitta på ett tredje alternativ.

Båda är legitima. Felet är att behandla dem som lager av en design, eftersom den andra modellen kan göra den förstas identitetsbyte till en operation som processen inte längre får utföra.

Avgör var identiteten byts

Om enheten redan startar som ett dedikerat konto kräver en demoninstruktion att bli ett annat konto ett setuid-byte som en härdad tjänst aldrig var tänkt att göra. Felet syns som ett behörighetsfel vid start i stället för som ett tydligt policymeddelande. Det läses som en saknad kapabilitet, vilket skickar folk mot en bredare begränsningsmängd i stället för mot identitetsfrågan.

Läs vad det installerade paketet faktiskt levererar innan du redigerar något, inklusive dess drop-in-katalog. Vissa enheter utelämnar medvetet demonens eget fall eftersom hanteraren redan sköter det, och vissa förlitar sig på de alternativen för bytet efter initieringen. Att ta bort något av dem utan att veta vilken modell du ärvt är hur en fungerande tjänst slutar starta.

Skriv den valda modellen på en rad: hanterarägd eller demonägd. Varje senare direktiv måste stämma med den meningen, och en blandad enhet bör behandlas som ett fel och inte som en kompromiss.

Kapabiliteter är gränser, inte gåvor

En kapabilitetsbegränsningsmängd säger vad en process högst får hålla. Det är ett tak, och att lista en kapabilitet där ger ingenting i sig, därför kan en enhet med en generös begränsningsmängd ändå misslyckas med att skapa en tunnel.

Det som faktiskt placerar en kapabilitet i en tjänsts omgivande mängd är AmbientCapabilities=. systemd-referensen för körning dokumenterar de två direktiven separat, och den skillnaden förklarar det mesta av den förvirrande kapabilitetsrådgivningen på nätet.

Lägg bara till en kapabilitet efter att den misslyckade operationen har identifierat den. En bredare begränsningsmängd döljer den verkliga orsaken och lämnar tjänsten mer privilegierad än designen avsåg. Det gör också enheten svårare att granska, eftersom taket inte längre beskriver arbetet. Ta bort den extra kapabiliteten när det egentliga felet är åtgärdat.

Kartlägg befogenheten genom livscykeln

Lista vad processen måste göra i varje fas: start, stabilt tillstånd, omauktorisering och nedmontering. Att skapa gränssnitt, ruttändringar, läsa en skyddad nyckel och anropa en hjälpare sker inte alla vid samma tidpunkt eller under samma krav. Sortera listan efter fas innan du sorterar den efter kapabilitet.

Beständighetsalternativ bevarar resurser genom omförhandling, och de ger inte behörigheter som aldrig har hållits. En nyckel som processen inte kan läsa vid start förblir oläsbar även senare, vad beständighetsflaggorna än säger. Flaggorna bevarar det som redan fungerade.

Använd ett dedikerat konto i stället för ett delat. OpenVPN-utvecklarna varnar för vanan att använda nobody som ett allmänt exempel, eftersom andra tjänster på värden kanske redan körs under det kontot och den isolering du tror dig ha finns inte där.

Funktioner som ändrar den lokala belastningen, som data-kanal-avlastning eller en byggnad som länkar annorlunda, kan flytta vilka operationer som behövs. Gå igenom kartan när paketet ändras, inte bara när något går sönder.

Skriv ned planen och behåll återställningsåtkomst

En driftsättningsjournal bör namnge hanteraren, startidentiteten, den avsedda stabila identiteten och varje tilldelning tillsammans med operationen som kräver den. Den journalen är det som gör nästa ändring granskningsbar i stället för experimentell.

Håll konsolåtkomst tillgänglig medan du redigerar, eftersom en enhet som misslyckas vid start är svår att reparera på distans. Testa en omstart och en full omstart innan du kallar ändringen klar. En enhet som överlever en omstart kan fortfarande misslyckas innan nätverket är uppe.

Framgång är en förstådd livscykel med minsta befogenhet, inte en process som råkar köra under ett namn som inte är root.