Не слажите очвршћивање systemd на спуштање user у OpenVPN

Два залепљена рецепта најмањих овлашћења не дају строже постављање. Један модел пушта демон да стартује са овлашћењима и спусти се на рачун без овлашћења након иницијализације; други пушта управљача сервиса да га покрене под ограниченим идентитетом од прве инструкције. Сваки ради сам за себе, а комбинација често даје сервис који не може чисто да обави ниједан од два посла. Остатак пролази кроз одлуку по реду.

Два модела, један власник пребацивања

Први модел припада демону. Опције OpenVPN заједнице user и group мењају идентитет након што су тунел и кључеви постављени, а persist-key плус persist-tun држе те ресурсе употребљивим након тога.

Други модел припада управљачу сервиса. Поставка systemd User= или Group= одлучује под којим идентитетом процес стартује, а директиве о способностима одлучују шта сме да држи. Биранје између модела је питање паковања пре него безбедносно питање, а одржавалац пакета је већ одговорио на њега. Ваш је посао да нађете тај одговор, а не да измислите трећу опцију.

Оба су легитимна. Грешка је третирати их као слојеве једног дизајна, јер други модел може да промену идентитета првога претвори у операцију коју процес више нема дозволу да изврши.

Одредите где се идентитет мења

Ако unit већ стартује као наменски рачун, додавање демонске инструкције да постане други рачун тражи setuid прелаз који очврсли сервис никада није требало да направи. Квар се појављује као грешка дозволе при старту, а не као јасна порука политике. То се чита као недостајућа способност, што људе води према ширем скупу ограничења уместо према питању идентитета.

Прочитајте шта инсталирани пакет заиста испоручује пре него што било шта уредите, укључујући његов drop-in директоријум. Неки unit-и намерно изостављају демонов властити спуст јер управљач то већ решава, а неки се ослањају на те опције за пребацивање након иницијализације. Уклањање било којег од њих без знања који сте модел наследили јесте начин на који радни сервис престаје да стартује.

Запишите изабрани модел у један ред: у власништву управљача или у власништву демона. Свака каснија директива мора бити усклађена с том реченицом, а мешани unit треба третирати као грешку, а не као компромис.

Способности су границе, не даривања

Скуп ограничења способности каже шта процес сме да држи највише. То је плафон, а навођење способности тамо само по себи ништа не даје, зато unit са издашним скупом ограничења ипак може да не успе да створи тунел.

Оно што заправо ставља способност у амбијентални скуп сервиса јесте AmbientCapabilities=. systemd референца за извршавање документује две директиве одвојено, а та разлика објашњава већину збуњујућих савета о способностима на интернету.

Додајте способност тек након што је операција која пада идентификује. Шири скуп ограничења скрива прави узрок и оставља сервис привилегованијим него што је дизајн намеравао. Такође чини unit тежим за преглед, јер плафон више не описује посао. Уклоните додатну способност кад се прави квар поправи.

Мапирајте овлашћење кроз животни циклус

Наведите шта процес мора да ради у свакој фази: старт, стабилно стање, поновна аутентификација и затварање. Стварање интерфејса, промене рута, читање заштићеног кључа и позивање помоћника не догађају се сви у истом тренутку ни под истим захтевима. Поредајте листу по фази пре него је поредате по способности.

Опције трајности чувају ресурсе кроз поновно преговарање и не дају дозволе које никада нису држане. Кључ који процес не може да прочита при старту остаће нечитљив и касније, шта год говориле заставице трајности. Заставице чувају оно што је већ радило.

Користите наменски рачун, а не заједнички. Програмери OpenVPN-а упозоравају на навику коришћења nobody као општег примера, јер други сервиси на хосту можда већ раде под тим рачуном и изолације коју мислите да имате нема.

Функције које мењају локално оптерећење, попут растерећења податковног канала или build-а који се другачије линкује, могу да поместе које су операције потребне. Прегледајте мапу кад се пакет промени, не само кад се нешто поквари.

Запишите план и задржите приступ за опоравак

Запис о постављању треба да именује управљача, идентитет при старту, намеравани стабилни идентитет и свако одобрење уз операцију која га захтева. Тај запис чини следећу промену прегледном уместо експерименталном.

Држите конзолни приступ доступним док уређујете, јер unit који падне при старту тешко је поправити на даљину. Тестирајте рестарт и потпуно поновно подизање пре него промену прогласите завршеном. Unit који преживи рестарт ипак може да падне пре него мрежа буде горе.

Успех је схваћен животни циклус са најмањим овлашћењима, а не процес који случајно ради под именом које није root.