Älä pinoa systemd-kovennusta OpenVPN:n user-vaihdon päälle

Kaksi yhteen liitettyä vähimmän oikeuden reseptiä eivät tuota tiukempaa käyttöönottoa. Toinen malli antaa daemonin käynnistyä oikeuksin ja pudota etuoikeudettomaan tilille alustuksen jälkeen; toinen antaa palvelunhallinnan käynnistää se rajoitetulla identiteetillä jo ensimmäisestä käskystä. Kumpikin toimii yksinään, ja yhdistelmä tuottaa usein palvelun, joka ei pysty tekemään puhtaasti kumpaakaan tehtävää. Loput tästä käy päätöksen läpi järjestyksessä.

Kaksi mallia, yksi vaihdon omistaja

Ensimmäinen malli kuuluu daemonille. Yhteisön OpenVPN-versiossa asetukset user ja group vaihtavat identiteettiä, kun tunneli ja avaimet on asetettu, ja persist-key yhdessä persist-tun-asetuksen kanssa pitävät nuo resurssit käytettävinä sen jälkeen.

Toinen malli kuuluu palvelunhallinnalle. systemd-asetus User= tai Group= päättää identiteetin, jonka alla prosessi käynnistyy, ja kyvykkyysohjeet päättävät, mitä se saa pitää. Mallien välinen valinta on paketointikysymys ennen kuin se on turvallisuuskysymys, ja paketin ylläpitäjä on jo vastannut siihen. Tehtäväsi on löytää se vastaus eikä keksiä kolmatta vaihtoehtoa.

Molemmat ovat legitiimejä. Virhe on kohdella niitä yhden suunnittelun kerroksina, koska toinen malli voi tehdä ensimmäisen identiteettivaihdosta toiminnon, jota prosessi ei enää saa suorittaa.

Päätä, missä identiteetti vaihtuu

Jos yksikkö käynnistyy jo omalta tililtä, daemonin käsky vaihtaa toiselle tilille vaatii setuid-siirtymän, jota kovennettua palvelua ei koskaan ollut tarkoitus tehdä. Vika näkyy käynnistyksen käyttöoikeusvirheenä eikä selvänä käytäntöviestinä. Se luetaan puuttuvaksi kyvykkyydeksi, mikä työntää ihmiset laajempaan rajoitusjoukkoon identiteettikysymyksen sijaan.

Lue, mitä asennettu paketti todella toimittaa, ennen kuin muokkaat mitään, mukaan lukien sen drop-in-hakemisto. Jotkin yksiköt jättävät daemonin oman pudotuksen tarkoituksella pois, koska hallinta hoitaa sen jo, ja jotkut nojaavat näihin asetuksiin alustuksen jälkeisessä vaihdossa. Kummankaan poistaminen tietämättä, minkä mallin perit, on tapa, jolla toimiva palvelu lakkaa käynnistymästä.

Kirjoita valittu malli yhdelle riville: hallinnan omistama tai daemonin omistama. Jokaisen myöhemmän ohjeen on oltava tuon lauseen mukainen, ja sekayksikköä on pidettävä virheenä eikä kompromissina.

Kyvykkyydet ovat rajoja, eivät myönnytyksiä

Kyvykkyysrajoitusjoukko kertoo, mitä prosessi saa enintään pitää. Se on katto, eikä kyvykkyyden listaaminen siinä anna itsessään mitään, minkä vuoksi runsaalla rajoitusjoukolla varustettu yksikkö voi silti epäonnistua tunnelin luomisessa.

Se, mikä tosiasiassa asettaa kyvykkyyden palvelun ympäröivään joukkoon, on AmbientCapabilities=. systemd:n suoritusviite dokumentoi nämä kaksi ohjetta erikseen, ja tämä ero selittää suurimman osan verkossa liikkuvista hämmentävistä kyvykkyysohjeista.

Lisää kyvykkyys vasta, kun epäonnistuva toiminto on tunnistanut sen. Laajempi rajoitusjoukko kätkee todellisen syyn ja jättää palvelun etuoikeutetummaksi kuin suunnittelu tarkoitti. Se tekee myös yksikön vaikeammaksi katselmoida, koska katto ei enää kuvaa työtä. Poista ylimääräinen kyvykkyys, kun varsinainen vika on korjattu.

Kartoita valtuus elinkaaren yli

Listaa, mitä prosessin on tehtävä kussakin vaiheessa: käynnistys, vakaa tila, uudelleentodennus ja purku. Rajapinnan luonti, reittimuutokset, suojatun avaimen lukeminen ja apurin kutsuminen eivät kaikki tapahdu samalla hetkellä tai samoilla vaatimuksilla. Järjestä lista vaiheen mukaan ennen kuin järjestät sen kyvykkyyden mukaan.

Pysyvyysasetukset säilyttävät resursseja uudelleenneuvottelun yli eivätkä myönnä oikeuksia, joita ei koskaan ollut. Avain, jota prosessi ei voi lukea käynnistyksessä, pysyy lukukelvottomana myöhemminkin, mitä pysyvyysliput sanovatkin. Liput säilyttävät sen, mikä jo toimi.

Käytä omaa tiliä jaetun sijaan. OpenVPN:n kehittäjät varoittavat tavasta käyttää nobody yleisenä esimerkkinä, koska muut palvelut isännässä voivat jo pyöriä sillä tilillä eikä eristystä, jonka luulet omaavasi, ole.

Paikallista kuormaa muuttavat ominaisuudet, kuten datakanavan purku tai eri tavoin linkittyvä käännös, voivat siirtää sitä, mitkä toiminnot tarvitaan. Käy kartta läpi, kun paketti muuttuu, ei vain silloin, kun jotain hajoaa.

Kirjoita suunnitelma muistiin ja pidä palautumispääsy tallessa

Käyttöönoton kirjauksen pitäisi nimetä hallinta, käynnistysidentiteetti, aiottu vakaa identiteetti ja jokainen myönnytys sekä sitä vaativa toiminto. Juuri se kirjaus tekee seuraavasta muutoksesta katselmoitavan eikä kokeellisen.

Pidä konsolipääsy saatavilla muokatessasi, koska käynnistyksessä epäonnistuvaa yksikköä on vaikea korjata etänä. Testaa uudelleenkäynnistys ja täysi uudelleenkäynnistys ennen kuin kutsut muutoksen valmiiksi. Uudelleenkäynnistyksen kestävä yksikkö voi silti epäonnistua ennen kuin verkko on ylhäällä.

Menestys on ymmärretty vähimmän valtuuden elinkaari, ei prosessi, joka sattuu pyörimään muun kuin root-nimen alla.