Не натрупвайте укрепването на systemd върху спускането на права в OpenVPN

Две рецепти за минимални права, слепени една за друга, не дават по-строго внедряване. Единият модел позволява на демона да стартира с права и да слезе до непривилегирован акаунт след инициализацията; другият кара мениджъра на услуги да го стартира с ограничена самоличност още от първата инструкция. Всяка работи сама по себе си, а комбинацията често дава услуга, която не може да свърши чисто нито една от двете задачи. Останалото тук проследява решението по ред.

Два модела, един собственик на превключването

Първият модел принадлежи на демона. Общностната версия на OpenVPN има опции user и group, които сменят самоличността след настройване на тунела и ключовете, а persist-key плюс persist-tun запазват тези ресурси използваеми след това.

Вторият модел принадлежи на мениджъра на услуги. Настройката User= или Group= на systemd определя самоличността, под която процесът стартира, а директивите за възможности определят какво може да държи. Изборът между моделите е въпрос на пакетиране преди да е въпрос на сигурност и поддържащият пакета вече е отговорил. Вашата задача е да намерите този отговор, а не да измислите трети вариант.

И двата са законни. Грешката е да ги третирате като слоеве на един дизайн, защото вторият модел може да превърне смяната на самоличността от първия в операция, която на процеса вече не е разрешено да извършва.

Решете къде се сменя самоличността

Ако юнитът вече стартира като отделен акаунт, добавянето на демонска инструкция да стане друг акаунт изисква setuid преход, който укрепена услуга никога не е била предназначена да прави. Провалът се появява като грешка за права при стартиране, а не като ясно съобщение за политика. Изглежда като липсваща възможност, което насочва хората към по-широк набор от ограничения вместо към въпроса за самоличността.

Прочетете какво всъщност доставя инсталираният пакет, преди да редактирате нещо, включително неговата drop-in директория. Някои юнити умишлено пропускат собствения спуск на демона, защото мениджърът вече се справя с него, а други разчитат на тези опции за превключването след инициализация. Премахването на което и да е от двете, без да знаете кой модел сте наследили, е начинът работеща услуга да спре да стартира.

Запишете избрания модел в един ред: собственост на мениджъра или на демона. Всяка следваща директива трябва да е в съответствие с това изречение, а смесен юнит трябва да се третира като дефект, а не като компромис.

Възможностите са граници, не дарения

Наборът от ограничения на възможности казва какво най-много може да държи един процес. Това е таван и изброяването на възможност там не дава нищо само по себе си; затова юнит с щедър набор от ограничения пак може да не създаде тунел.

Това, което наистина поставя възможност в околния набор на услуга, е AmbientCapabilities=. Справочникът за изпълнение на systemd документира двете директиви поотделно и това разграничение обяснява повечето объркващи съвети за възможности онлайн.

Добавяйте възможност само след като провалящата се операция я идентифицира. По-широкият набор от ограничения скрива истинската причина и оставя услугата по-привилегирована, отколкото дизайнът е предвидил. Той също прави юнита по-труден за преглед, защото таванът вече не описва работата. Премахнете допълнителната възможност, след като истинската повреда е поправена.

Разпределете правомощията по жизнения цикъл

Избройте какво трябва да прави процесът на всеки етап: стартиране, устойчиво състояние, повторно удостоверяване и приключване. Създаването на интерфейс, промените на маршрути, четенето на защитен ключ и извикването на помощник не се случват в един и същ момент или при едни и същи изисквания. Подредете списъка по етап, преди да го подредите по възможност.

Опциите за устойчивост запазват ресурси между преговорите и не дават права, които никога не са били притежавани. Ключ, който процесът не може да прочете при стартиране, ще остане нечетим и по-късно, каквото и да казват флаговете за устойчивост. Флаговете запазват това, което вече е работело.

Използвайте отделен акаунт, а не споделен. Разработчиците на OpenVPN предупреждават срещу навика да се използва nobody като общ пример, защото други услуги на хоста може вече да работят с този акаунт и изолацията, която смятате, че имате, я няма.

Функции, които променят локалното натоварване, като разтоварване на канала за данни или компилация с различно свързване, могат да променят кои операции са нужни. Преглеждайте картата, когато пакетът се промени, не само когато нещо се счупи.

Запишете плана и запазете достъп за възстановяване

Записът за внедряване трябва да назове мениджъра, самоличността при стартиране, желаната устойчива самоличност и всяко разрешение заедно с операцията, която го изисква. Този запис прави следващата промяна прегледима, а не експериментална.

Пазете достъп до конзола, докато редактирате, защото юнит, който се проваля при стартиране, е труден за отдалечен ремонт. Тествайте рестарт и пълно презареждане, преди да обявите промяната за завършена. Юнит, който оцелява при рестарт, пак може да се провали преди мрежата да е активна.

Успехът е разбран жизнен цикъл с минимални правомощия, а не процес, който случайно работи под име, различно от root.