Ikkje stabla systemd-herding på user-nedfallet i OpenVPN
To oppskrifter med minst mogleg rettar saman er ikkje ei strengare. Vel kven som gjer identitetsskiftet, og kartlegg deretter myndet gjennom heile livssyklusen.
To oppskrifter med minst mogleg rettar som blir limte saman gir ikkje ei strengare utrulling. Den eine modellen lèt daemonen starte med rettar og falle ned til ein konto utan rettar etter initialiseringa; den andre lèt tenestestyringa starte han under ein avgrensa identitet heilt frå den første instruksjonen. Kvar for seg verkar dei, og kombinasjonen gir ofte ei teneste som ikkje klarar nokon av dei to oppgåvene ordentleg. Resten går gjennom avgjerda i rekkefølgje.
To modellar, éin eigar av skiftet
Den første modellen høyrer til daemonen. Fellesskapsversjonen av OpenVPN har alternativa user og group, som byter identitet etter at tunnelen og nøklane er sette opp, og persist-key pluss persist-tun held desse ressursane brukbare etterpå.
Den andre modellen høyrer til tenestestyringa. Ei systemd-innstilling User= eller Group= avgjer identiteten prosessen startar under, og kapabilitetsdirektiv avgjer kva han får halde. Valet mellom modellane er eit pakkjeringsspørsmål før det er eit tryggleiksspørsmål, og pakkevedlikehaldaren har alt svara på det. Oppgåva di er å finne det svaret i staden for å finne opp eit tredje alternativ.
Begge er legitime. Feilen er å handsame dei som lag av eitt design, fordi den andre modellen kan gjere identitetsskiftet til den første til ein operasjon prosessen ikkje lenger har lov til å utføre.
Avgjer kvar identiteten skiftar
Viss eininga alt startar som ein dedikert konto, krev ein daemoninstruks om å bli ein annan konto ein setuid-overgang som ei herda teneste aldri var meint å gjere. Feilen viser seg som ein løyvefeil ved oppstart i staden for som ei klar retningslinjemelding. Det blir lese som ein manglande kapabilitet, noko som sender folk mot eit breiare avgrensingssett i staden for mot identitetsspørsmålet.
Les kva den installerte pakken faktisk leverer før du redigerer noko, inkludert drop-in-katalogen. Nokre einingar utelèt med vilje daemonens eige fall fordi styringa alt handterer det, og nokre er avhengige av desse alternativa for skiftet etter initialisering. Å fjerne ein av dei utan å vite kva modell du har arva, er måten ei fungerande teneste sluttar å starte på.
Skriv den valde modellen på éi linje: styringseigd eller daemoneigd. Kvar seinare direktiv må vere i samsvar med den setninga, og ei blanda eining bør handsamast som ein feil og ikkje som eit kompromiss.
Kapabilitetar er grenser, ikkje tildelingar
Eit kapabilitetsavgrensingssett seier kva ein prosess maksimalt får halde. Det er eit tak, og å liste ein kapabilitet der gir ingenting i seg sjølv, difor kan ei eining med eit rundhanda avgrensingssett framleis ikkje klare å lage ein tunnel.
Det som faktisk plasserer ein kapabilitet i det omgjevande settet for ei teneste, er AmbientCapabilities=. systemd-referansen for køyring dokumenterer dei to direktiva kvar for seg, og denne skilnaden forklarer det meste av den forvirrande kapabilitetsrådgjevinga på nettet.
Legg berre til ein kapabilitet etter at den feilande operasjonen har identifisert han. Eit breiare avgrensingssett skjuler den eigentlege årsaka og lèt tenesta stå med meir rettar enn designet tilsikta. Det gjer òg eininga vanskelegare å gjennomgå, fordi taket ikkje lenger skildrar arbeidet. Fjern den ekstra kapabiliteten når den eigentlege feilen er retta.
Kartlegg myndet gjennom livssyklusen
List opp kva prosessen må gjere i kvar fase: oppstart, stabil tilstand, reautentisering og nedrigging. Oppretting av grensesnitt, ruteendringar, lesing av ein verna nøkkel og kall på ein hjelpar skjer ikkje alle på same tidspunkt eller under same krav. Sorter lista etter fase før du sorterer henne etter kapabilitet.
Vedlikehaldsinnstillingar bevarer ressursar gjennom reforhandling, og dei gir ikkje løyve som aldri har vore haldne. Ein nøkkel prosessen ikkje kan lese ved oppstart, vil framleis vere uleseleg seinare, uansett kva vedlikehaldsflaggene seier. Flagga bevarer det som alt verka.
Bruk ein dedikert konto i staden for ein delt. OpenVPN-utviklarane åtvarar mot vanen med å bruke nobody som eit generelt døme, fordi andre tenester på verten kanskje alt køyrer som den kontoen, og isolasjonen du trur du har, er ikkje der.
Funksjonar som endrar den lokale belastninga, som data-kanal-avlasting eller ein bygg som lenkjer annleis, kan flytte kva operasjonar som trengst. Sjå over kartet når pakken endrar seg, ikkje berre når noko går i stykker.
Skriv ned planen og hald gjenopprettingstilgang
Ein utrullingsjournal bør namngi styringa, oppstartsidentiteten, den tiltenkte stabile identiteten og kvar tildeling saman med operasjonen som krev henne. Den journalen er det som gjer den neste endringa gjennomgåeleg i staden for eksperimentell.
Hald konsolltilgang tilgjengeleg medan du redigerer, fordi ei eining som feilar ved oppstart er vanskeleg å reparere eksternt. Test ein omstart og ein full omstart før du kallar endringa ferdig. Ei eining som overlever ein omstart, kan framleis feile før nettverket er oppe.
Suksess er ein forstått livssyklus med minst mogleg mynd, ikkje ein prosess som tilfeldigvis køyrer under eit namn som ikkje er root.