Stabl ikke systemd-hærdning oven på OpenVPNs skift til user

To opskrifter med mindst mulige rettigheder, der klistres sammen, giver ikke en strengere udrulning. Den ene model lader dæmonen starte med rettigheder og falde til en konto uden rettigheder efter initialisering; den anden lader tjenestestyringen starte den under en begrænset identitet fra den første instruktion. Hver især virker de alene, og kombinationen giver ofte en tjeneste, der ikke kan udføre nogen af de to opgaver rent. Resten her går beslutningen igennem i rækkefølge.

To modeller, én ejer af skiftet

Den første model tilhører dæmonen. Fællesskabsudgaven af OpenVPN har indstillingerne user og group, som skifter identitet, når tunnelen og nøglerne er sat op, og persist-key plus persist-tun holder disse ressourcer brugbare bagefter.

Den anden model tilhører tjenestestyringen. En systemd-indstilling User= eller Group= afgør den identitet, processen starter under, og kapabilitetsdirektiver afgør, hvad den må holde. Valget mellem modellerne er et pakkeringsspørgsmål, før det er et sikkerhedsspørgsmål, og pakkevedligeholderen har allerede besvaret det. Din opgave er at finde det svar i stedet for at opfinde en tredje mulighed.

Begge er legitime. Fejlen er at behandle dem som lag af ét design, fordi den anden model kan gøre den førstes identitetsskifte til en handling, som processen ikke længere har lov til at udføre.

Afgør, hvor identiteten skifter

Hvis unit'en allerede starter som en dedikeret konto, kræver en dæmoninstruks om at blive en anden konto en setuid-overgang, som en hærdet tjeneste aldrig var beregnet til at lave. Fejlen viser sig som en tilladelsesfejl ved opstart i stedet for som en klar politikbesked. Det læses som en manglende kapabilitet, hvilket sender folk mod et bredere afgrænsningssæt i stedet for mod identitetsspørgsmålet.

Læs, hvad den installerede pakke faktisk leverer, før du redigerer noget, inklusive dens drop-in-mappe. Nogle unit'er udelader bevidst dæmonens eget fald, fordi styringen allerede håndterer det, og nogle er afhængige af de indstillinger til skiftet efter initialisering. At fjerne en af dem uden at vide, hvilken model du har arvet, er måden, en fungerende tjeneste holder op med at starte.

Skriv den valgte model på én linje: styringsejet eller dæmonejet. Hvert senere direktiv skal være i overensstemmelse med den sætning, og en blandet unit bør behandles som en fejl snarere end et kompromis.

Kapabiliteter er grænser, ikke tildelinger

Et kapabilitetsafgrænsningssæt siger, hvad en proces højst må holde. Det er et loft, og at liste en kapabilitet der giver intet i sig selv, og derfor kan en unit med et rundhåndet afgrænsningssæt stadig ikke skabe en tunnel.

Det, der faktisk placerer en kapabilitet i det omgivende sæt for en tjeneste, er AmbientCapabilities=. systemd's eksekveringsreference dokumenterer de to direktiver hver for sig, og denne forskel forklarer det meste af den forvirrende kapabilitetsrådgivning på nettet.

Tilføj først en kapabilitet, når den fejlende handling har identificeret den. Et bredere afgrænsningssæt skjuler den egentlige årsag og efterlader tjenesten mere privilegeret, end designet tilsigtede. Det gør også unit'en sværere at gennemgå, fordi loftet ikke længere beskriver opgaven. Fjern den ekstra kapabilitet, når den egentlige fejl er rettet.

Kortlæg beføjelser gennem livscyklussen

List, hvad processen skal gøre på hvert trin: opstart, stabil tilstand, reautentificering og nedlukning. Oprettelse af grænseflader, ruteændringer, læsning af en beskyttet nøgle og kald af en hjælper sker ikke alle på samme tidspunkt eller under samme krav. Sortér listen efter trin, før du sorterer den efter kapabilitet.

Vedholdenhedsindstillinger bevarer ressourcer gennem genforhandling, og de giver ikke tilladelser, der aldrig har været holdt. En nøgle, som processen ikke kan læse ved opstart, vil stadig være ulæselig senere, uanset hvad vedholdenhedsflagene siger. Flagene bevarer det, der allerede virkede.

Brug en dedikeret konto i stedet for en delt. OpenVPN-udviklerne advarer mod vanen med at bruge nobody som et generisk eksempel, fordi andre tjenester på værten måske allerede kører som den konto, og den isolering, du tror, du har, er der ikke.

Funktioner, der ændrer den lokale belastning, såsom data-kanal-offload eller et build, der linkes anderledes, kan flytte, hvilke handlinger der er nødvendige. Tag kortet op igen, når pakken ændres, ikke kun når noget går i stykker.

Skriv planen ned, og bevar genopretningsadgang

En udrulningsjournal bør navngive styringen, opstartsidentiteten, den tilsigtede stabile identitet og hver tildeling sammen med den handling, der kræver den. Den journal er det, der gør den næste ændring gennemgåelig i stedet for eksperimentel.

Hold konsoladgang tilgængelig, mens du redigerer, fordi en unit, der fejler ved opstart, er svær at reparere eksternt. Test en genstart og en fuld genstart, før du kalder ændringen færdig. En unit, der overlever en genstart, kan stadig fejle, før netværket er oppe.

Succes er en forstået livscyklus med mindst mulige beføjelser, ikke en proces, der tilfældigvis kører under et navn, der ikke er root.