Услугата стартира, журналът се оплаква, че не може да отвори устройството tun, а маршрутите така и не се появяват. Изпълнете capsh --print в своята обвивка и cap_net_admin е точно там, което прави отказа да изглежда невъзможен. Разликата между вашата обвивка и модула е преходът на привилегии, а не желанието на ядрото да отпусне възможността. Преминете през четирите проверки по-долу по ред и спрете на първата, която обяснява разликата.

Отделете липсващата възможност от скритото устройство

Два отказа изглеждат еднакво от реда в журнала. Процес без CAP_NET_ADMIN не може да създаде или конфигурира интерфейса на тунела, а процес, чиято пясъчна среда скрива /dev/net/tun, не може да го отвори още в началото. Добавянето на възможности няма да поправи втория случай.

Проверете дали устройството съществува в пространството от имена на услугата, преди да редактирате каквото и да е. PrivateDevices=yes е често срещан ред за затягане, който премахва възела tun изцяло, а ограничителен ProtectSystem може да направи пътя за конфигурация само за четене по начин, който се чете като грешка в правата. И двете дават редове в журнала, които споменават тунела, затова вината се хвърля върху възможностите. Първо потвърдете, че възелът е наличен и отваряем, после продължете.

Знайте кой набор от възможности разглеждате

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

Тук sudo подвежда хората. Команда, изпълнена чрез sudo -u, започва нов преход на привилегии и околният набор изчезва, затова същата проверка, която успява като root, там се проваля. Мениджърът на услуги е още един преход и не дава нищо околно, освен ако модулът не го заяви.

Дайте възможността в модула, а не в обвивка

Минимален раздел за услуга на тунел, който трябва да създаде устройство и да инсталира маршрути, изглежда така.

[Unit]
Description=OpenVPN client, office profile
After=network-online.target

[Service]
Type=notify
User=openvpn
Group=openvpn
NoNewPrivileges=yes
AmbientCapabilities=CAP_NET_ADMIN
CapabilityBoundingSet=CAP_NET_ADMIN
ExecStart=/usr/sbin/openvpn --config /etc/openvpn/office.conf

AmbientCapabilities поставя правото в околния набор преди стартирането на процеса, а CapabilityBoundingSet не позволява на процеса да държи нещо извън този списък. NoNewPrivileges=yes блокира придобиването на привилегии чрез setuid или файлови възможности, докато възможността, която модулът дава изрично, все още важи. Добавяйте CAP_NET_BIND_SERVICE само когато услугата трябва да заеме нисък порт, и никога не добавяйте CAP_SYS_ADMIN само защото форумна тема го е направила.

Ако модулът обвива изпълнимия файл в sudo, премахнете обвивката. systemd вече прилага User= и този допълнителен слой е най-вероятната причина околният набор да е празен.

Проверявайте срещу живия процес, а не срещу файла на модула

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

unit=openvpn-client@office
systemctl show -p User -p AmbientCapabilities "$unit"
systemctl show -p MainPID --value "$unit" | xargs -r getpcaps
grep -E '^Cap(Eff|Amb)' /proc/$(systemctl show -p MainPID --value "$unit")/status

Ако модулът изброява възможността, а CapEff все още я няма, някой drop-in замества настройката или стъпка ExecStartPre променя средата. Търсете името на модула в директориите за drop-in, преди да приемете, че основният файл е меродавен, защото по-късен файл печели безшумно. Ако и модулът, и процесът показват възможността, а тунелът все още се проваля, върнете се към проверките на устройството и пътя, вместо да разширявате ограничаващия набор. Разширяването му скрива истинската причина и оставя услугата по-привилегирована, отколкото е била.

Предпочитайте да свалите привилегиите след стартиране

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

Който и модел да изберете, рестартирайте модула и повторете проверките след презареждане, защото услуга, която работи от интерактивна root обвивка и се проваля при зареждане, обикновено е разлика във възможност, устройство или файлови права. Запишете настройките на модула до изхода за възможностите на процеса, за да види следващият рецензент дали ъпдейт на пакет или drop-in е преместил границата.

Подобни статии