Ne halmozza a systemd megerősítését az OpenVPN user-átadására

Két összeragasztott minimális jogosultságú recept együtt nem eredményez szigorúbb telepítést. Az egyik modell engedi, hogy a démon jogosultságokkal induljon, majd inicializálás után egy nem jogosult fiókra váltson; a másik a szolgáltatáskezelővel már az első utasítástól fogva korlátozott identitás alatt indítja. Mindkettő működik önmagában, a kombináció pedig gyakran olyan szolgáltatást ad, amely egyik feladatot sem tudja tisztán ellátni. A többi rész sorban végigveszi a döntést.

Két modell, a váltás egyetlen tulajdonosa

Az első modell a démoné. A közösségi OpenVPN user és group beállításai az alagút és a kulcsok beállítása után váltják az identitást, a persist-key pedig a persist-tun-tal együtt használhatóvá tartja ezeket az erőforrásokat utána.

A második modell a szolgáltatáskezelőé. Egy systemd User= vagy Group= beállítás dönti el, milyen identitás alatt indul a folyamat, a képesség-utasítások pedig azt, mit tarthat. A modellek közötti választás csomagolási kérdés, mielőtt biztonsági kérdés lenne, és a csomag karbantartója már megválaszolta. Az Ön feladata, hogy megtalálja ezt a választ, ne pedig kitaláljon egy harmadik lehetőséget.

Mindkettő legitim. A hiba az, hogy egy tervezés rétegeiként kezeljük őket, mert a második modell az első identitásváltását olyan műveletté teheti, amelyre a folyamatnak már nincs engedélye.

Döntse el, hol változik az identitás

Ha az unit már dedikált fiókként indul, a démonnak adott utasítás, hogy másik fiókká váljon, olyan setuid-átmenetet kér, amelyet egy megerősített szolgáltatásnak soha nem kellett volna megtennie. A hiba indításkor engedélyhibaként jelenik meg, nem világos házirend-üzenetként. Hiányzó képességnek tűnik, ami az embereket szélesebb korlátozás-készlet felé tereli az identitás kérdése helyett.

Olvassa el, mit szállít valójában a telepített csomag, mielőtt bármit szerkesztene, beleértve a drop-in könyvtárát. Egyes unitek szándékosan kihagyják a démon saját váltását, mert a kezelő már kezeli azt, mások pedig ezekre a beállításokra támaszkodnak az inicializálás utáni váltáshoz. Bármelyik eltávolítása anélkül, hogy tudná, melyik modellt örökölte, az az út, amelyen egy működő szolgáltatás abbahagyja az indulást.

Írja le a választott modellt egy sorban: kezelő-tulajdonú vagy démon-tulajdonú. Minden későbbi utasításnak összhangban kell lennie ezzel a mondattal, a kevert unitot pedig hibaként, nem kompromisszumként kell kezelni.

A képességek határok, nem adományok

Egy képesség-korlátozás készlet azt mondja meg, mit tarthat egy folyamat legfeljebb. Ez egy plafon, és egy képesség ott való felsorolása önmagában semmit nem ad, ezért egy bőkezű korlátozás-készlettel rendelkező unit még mindig nem tud alagutat létrehozni.

Ami valóban behelyezi a képességet egy szolgáltatás környezeti készletébe, az a AmbientCapabilities=. A systemd végrehajtási referenciája külön dokumentálja a két utasítást, és ez a különbség magyarázza az online képesség-tanácsok nagy részét.

Csak azután adjon hozzá képességet, hogy a sikertelen művelet azonosította. A szélesebb korlátozás-készlet elrejti a valódi okot, és a szolgáltatást a tervezettnél nagyobb jogosultságokkal hagyja. Az unit áttekintését is nehezíti, mert a plafon már nem írja le a munkát. A valódi hiba javítása után távolítsa el a felesleges képességet.

Képezze le a felhatalmazást az életciklusra

Sorolja fel, mit kell a folyamatnak tennie az egyes szakaszokban: indítás, állandósult állapot, újrahitelesítés és lebontás. A csatoló létrehozása, az útvonal-változtatások, egy védett kulcs olvasása és egy segéd meghívása nem mind ugyanabban a pillanatban vagy ugyanazon követelmények mellett történik. Rendezze a listát szakasz szerint, mielőtt képesség szerint rendezné.

A tartóssági beállítások erőforrásokat őriznek meg az újratárgyalás során, és nem adnak olyan engedélyeket, amelyek soha nem voltak birtokukban. Egy kulcs, amelyet a folyamat indításkor nem tud olvasni, később is olvashatatlan marad, bármit mondanak a tartóssági jelzők. A jelzők azt őrzik meg, ami már működött.

Dedikált fiókot használjon megosztott helyett. Az OpenVPN fejlesztői óvnak attól a szokástól, hogy a nobody fiókot általános példaként használjuk, mert a gazdagépen más szolgáltatások már futhatnak azon a fiókon, és az a szigetelés, amelyről azt hiszi, hogy van, nincs ott.

A helyi terhelést megváltoztató funkciók, például az adatcsatorna-kiszervezés vagy egy másként linkelő build elmozdíthatják, milyen műveletek szükségesek. Nézze át a térképet, amikor a csomag változik, ne csak amikor valami elromlik.

Írja le a tervet, és tartsa meg a helyreállítási hozzáférést

Egy telepítési feljegyzésnek meg kell neveznie a kezelőt, az indítási identitást, a szándékolt állandósult identitást és minden engedményt az azt igénylő művelettel együtt. Ez a feljegyzés teszi a következő változtatást áttekinthetővé kísérlet helyett.

Tartsa elérhetővé a konzolhozzáférést szerkesztés közben, mert egy indításkor meghiúsuló unitot nehéz távolról javítani. Teszteljen újraindítást és teljes újraindítást, mielőtt késznek nyilvánítja a változtatást. Egy újraindítást túlélő unit még mindig meghiúsulhat, mielőtt a hálózat feláll.

A siker egy megértett minimális felhatalmazású életciklus, nem egy folyamat, amely véletlenül nem root néven fut.