Ikke stable systemd-herding på OpenVPNs user-nedfall

To oppskrifter med minst mulig rettigheter som limes sammen gir ikke en strengere utrulling. Den ene modellen lar daemonen starte med rettigheter og falle ned til en konto uten rettigheter etter initialiseringen; den andre lar tjenestestyringen starte den under en begrenset identitet helt fra den første instruksjonen. Hver for seg virker de, og kombinasjonen gir ofte en tjeneste som ikke klarer noen av de to oppgavene ordentlig. Resten går gjennom beslutningen i rekkefølge.

To modeller, én eier av skiftet

Den første modellen tilhører daemonen. Fellesskapsversjonen av OpenVPN har alternativene user og group, som bytter identitet etter at tunnelen og nøklene er satt opp, og persist-key pluss persist-tun holder disse ressursene brukbare etterpå.

Den andre modellen tilhører tjenestestyringen. En systemd-innstilling User= eller Group= avgjør identiteten prosessen starter under, og kapabilitetsdirektiver avgjør hva den får holde. Valget mellom modellene er et pakkeringsspørsmål før det er et sikkerhetsspørsmål, og pakkevedlikeholderen har allerede svart på det. Oppgaven din er å finne det svaret i stedet for å finne opp et tredje alternativ.

Begge er legitime. Feilen er å behandle dem som lag av ett design, fordi den andre modellen kan gjøre den førstes identitetsskifte til en operasjon prosessen ikke lenger har lov til å utføre.

Avgjør hvor identiteten skifter

Hvis enheten allerede starter som en dedikert konto, krever en daemoninstruks om å bli en annen konto en setuid-overgang som en herdet tjeneste aldri var ment å gjøre. Feilen vises som en tillatelsesfeil ved oppstart i stedet for som en klar policy-melding. Det leses som en manglende kapabilitet, noe som sender folk mot et bredere avgrensningssett i stedet for mot identitetsspørsmålet.

Les hva den installerte pakken faktisk leverer før du redigerer noe, inkludert drop-in-katalogen. Noen enheter utelater med vilje daemonens eget fall fordi styringen allerede håndterer det, og noen er avhengige av disse alternativene for skiftet etter initialisering. Å fjerne en av dem uten å vite hvilken modell du har arvet, er måten en fungerende tjeneste slutter å starte på.

Skriv den valgte modellen på én linje: styringseid eller daemoneid. Hver senere direktiv må være i samsvar med den setningen, og en blandet enhet bør behandles som en feil og ikke som et kompromiss.

Kapabiliteter er grenser, ikke tildelinger

Et kapabilitetsavgrensningssett sier hva en prosess maksimalt får holde. Det er et tak, og å liste en kapabilitet der gir ingenting i seg selv, derfor kan en enhet med et rundhåndet avgrensningssett fortsatt ikke klare å lage en tunnel.

Det som faktisk plasserer en kapabilitet i det omgivende settet for en tjeneste, er AmbientCapabilities=. systemd-referansen for kjøring dokumenterer de to direktivene hver for seg, og denne forskjellen forklarer det meste av den forvirrende kapabilitetsrådgivningen på nettet.

Legg bare til en kapabilitet etter at den feilende operasjonen har identifisert den. Et bredere avgrensningssett skjuler den egentlige årsaken og lar tjenesten stå med mer rettigheter enn designet tilsiktet. Det gjør også enheten vanskeligere å gjennomgå, fordi taket ikke lenger beskriver arbeidet. Fjern den ekstra kapabiliteten når den egentlige feilen er rettet.

Kartlegg myndigheten gjennom livssyklusen

List opp hva prosessen må gjøre i hver fase: oppstart, stabil tilstand, reautentisering og nedrigging. Oppretting av grensesnitt, ruteendringer, lesing av en beskyttet nøkkel og kall på en hjelper skjer ikke alle på samme tidspunkt eller under samme krav. Sorter listen etter fase før du sorterer den etter kapabilitet.

Vedlikeholdsinnstillinger bevarer ressurser gjennom reforhandling, og de gir ikke tillatelser som aldri har vært holdt. En nøkkel prosessen ikke kan lese ved oppstart, vil fortsatt være uleselig senere, uansett hva vedlikeholdsflaggene sier. Flaggene bevarer det som allerede virket.

Bruk en dedikert konto i stedet for en delt. OpenVPN-utviklerne advarer mot vanen med å bruke nobody som et generelt eksempel, fordi andre tjenester på verten kanskje allerede kjører som den kontoen, og isolasjonen du tror du har, er ikke der.

Funksjoner som endrer den lokale belastningen, som data-kanal-avlastning eller en bygg som lenker annerledes, kan flytte hvilke operasjoner som trengs. Se over kartet når pakken endres, ikke bare når noe går i stykker.

Skriv ned planen og behold gjenopprettingstilgang

En utrullingsjournal bør navngi styringen, oppstartsidentiteten, den tiltenkte stabile identiteten og hver tildeling sammen med operasjonen som krever den. Den journalen er det som gjør den neste endringen gjennomgåelig i stedet for eksperimentell.

Hold konsolltilgang tilgjengelig mens du redigerer, fordi en enhet som feiler ved oppstart er vanskelig å reparere eksternt. Test en omstart og en full omstart før du kaller endringen ferdig. En enhet som overlever en omstart, kan fortsatt feile før nettverket er oppe.

Suksess er en forstått livssyklus med minst mulig myndighet, ikke en prosess som tilfeldigvis kjører under et navn som ikke er root.