Dva recepta najmanjih privilegija zalijepljena zajedno ne daju strože postavljanje. Jedan model pušta daemon da starta s privilegijama i spusti se na neprivilegirani račun nakon inicijalizacije; drugi pušta upravitelja servisa da ga pokrene pod ograničenim identitetom od prve instrukcije. Svaki radi sam za sebe, a kombinacija često daje servis koji ne može čisto obaviti nijedan od dva posla. Ostatak ovoga prolazi kroz odluku po redu.

Dva modela, jedan vlasnik prebacivanja

Prvi model pripada daemonu. Opcije OpenVPN zajednice user i group mijenjaju identitet nakon što su tunel i ključevi postavljeni, a persist-key plus persist-tun drže te resurse upotrebljivima nakon toga.

Drugi model pripada upravitelju servisa. Postavka systemd User= ili Group= odlučuje pod kojim identitetom proces starta, a direktive o sposobnostima odlučuju šta smije držati. Biranje između modela je pitanje pakiranja prije nego sigurnosno pitanje, a održavatelj paketa je već odgovorio na njega. Vaš posao je da nađete taj odgovor, a ne da izmislite treću opciju.

Oba su legitimna. Greška je tretirati ih kao slojeve jednog dizajna, jer drugi model može promjenu identiteta prvoga pretvoriti u operaciju koju proces više nema dozvolu izvršiti.

Odredite gdje se identitet mijenja

Ako unit već starta kao namjenski račun, dodavanje daemonske instrukcije da postane drugi račun traži setuid prijelaz koji očvrsnuti servis nikada nije trebao napraviti. Kvar se pojavljuje kao greška dozvole pri startu, a ne kao jasna poruka politike. To se čita kao nedostajuća sposobnost, što ljude vodi prema širem skupu ograničenja umjesto prema pitanju identiteta.

Pročitajte šta instalirani paket zaista isporučuje prije nego što bilo šta uredite, uključujući njegov drop-in direktorij. Neki uniti namjerno izostavljaju daemonov vlastiti spust jer upravitelj to već rješava, a neki se oslanjaju na te opcije za prebacivanje nakon inicijalizacije. Uklanjanje bilo kojeg od njih bez znanja koji ste model naslijedili jeste način na koji radni servis prestaje startati.

Zapišite odabrani model u jedan red: u vlasništvu upravitelja ili u vlasništvu daemona. Svaka kasnija direktiva mora biti usklađena s tom rečenicom, a miješani unit treba tretirati kao grešku, a ne kao kompromis.

Sposobnosti su granice, ne darivanja

Skup ograničenja sposobnosti kaže šta proces smije držati najviše. To je plafon, a navođenje sposobnosti tamo samo po sebi ništa ne daje, zato unit s izdašnim skupom ograničenja ipak može ne uspjeti stvoriti tunel.

Ono što zapravo stavlja sposobnost u ambijentalni skup servisa jeste AmbientCapabilities=. systemd referenca za izvršavanje dokumentuje dvije direktive odvojeno, a ta razlika objašnjava većinu zbunjujućih savjeta o sposobnostima na internetu.

Dodajte sposobnost tek nakon što je operacija koja pada identificira. Širi skup ograničenja skriva pravi uzrok i ostavlja servis privilegovanijim nego što je dizajn namjeravao. Također čini unit težim za pregled, jer plafon više ne opisuje posao. Uklonite dodatnu sposobnost kad se pravi kvar popravi.

Mapirajte ovlaštenja kroz životni ciklus

Navedite šta proces mora raditi u svakoj fazi: start, stabilno stanje, ponovna autentifikacija i zatvaranje. Stvaranje interfejsa, promjene ruta, čitanje zaštićenog ključa i pozivanje pomoćnika ne događaju se svi u istom trenutku ni pod istim zahtjevima. Poredajte listu po fazi prije nego je poredate po sposobnosti.

Opcije trajnosti čuvaju resurse kroz ponovno pregovaranje i ne daju dozvole koje nikada nisu držane. Ključ koji proces ne može pročitati pri startu ostat će nečitljiv i kasnije, šta god govorile zastavice trajnosti. Zastavice čuvaju ono što je već radilo.

Koristite namjenski račun, a ne zajednički. Programeri OpenVPN-a upozoravaju na naviku korištenja nobody kao općenitog primjera, jer drugi servisi na hostu možda već rade pod tim računom i izolacije koju mislite da imate nema.

Značajke koje mijenjaju lokalno opterećenje, poput rasterećenja podatkovnog kanala ili builda koji se drugačije linka, mogu promijeniti koje su operacije potrebne. Pregledajte mapu kad se paket promijeni, ne samo kad se nešto pokvari.

Zapišite plan i zadržite pristup za oporavak

Zapis o postavljanju treba imenovati upravitelja, identitet pri startu, namjeravani stabilni identitet i svako odobrenje uz operaciju koja ga zahtijeva. Taj zapis čini sljedeću promjenu preglednom umjesto eksperimentalnom.

Držite konzolni pristup dostupnim dok uređujete, jer unit koji padne pri startu teško je popraviti na daljinu. Testirajte restart i potpuno ponovno podizanje prije nego promjenu proglasite završenom. Unit koji preživi restart ipak može pasti prije nego mreža bude gore.

Uspjeh je shvaćen životni ciklus s najmanjim ovlaštenjima, a ne proces koji slučajno radi pod imenom koje nije root.

Povezani članci