Non apiles o endurecemento de systemd sobre a baixada de usuario de OpenVPN

Dúas receitas de mínimo privilexio pegadas xuntas non producen un despregamento máis estrito. Un modelo deixa que o daemon arranque con privilexios e baixe a unha conta sen privilexios tras a inicialización; o outro fai que o xestor de servizos o lance cunha identidade restrinxida desde a primeira instrución. Cada un funciona por si só, e a combinación adoita producir un servizo que non pode facer limpiamente ningún dos dous traballos. O resto disto percorre a decisión por orde.

Dous modelos, un só dono do cambio

O primeiro modelo pertence ao daemon. As opcións OpenVPN da comunidade user e group cambian a identidade unha vez configurados o túnel e as claves, e persist-key máis persist-tun manteñen eses recursos utilizables despois.

O segundo modelo pertence ao xestor de servizos. Un axuste systemd User= ou Group= decide a identidade coa que arranca o proceso, e as directivas de capacidades deciden que pode reter. Escoller entre os modelos é unha cuestión de empaquetado antes que de seguridade, e o mantedor do paquete xa a respondeu. O seu traballo é atopar esa resposta en lugar de inventar unha terceira opción.

Ambos son lexítimos. O erro é tratalos como capas dun mesmo deseño, porque o segundo modelo pode converter o cambio de identidade do primeiro nunha operación que o proceso xa non ten permiso de realizar.

Decida onde cambia a identidade

Se a unidade xa arranca como unha conta dedicada, engadir unha instrución do daemon para pasar a outra conta pide unha transición setuid que un servizo endurecido nunca debera facer. O fallo aparece como un erro de permisos ao arrancar en lugar de como unha mensaxe de política clara. Les como unha capacidade que falta, o que empurra á xente cara a un conxunto de límites máis amplo en vez de cara á cuestión da identidade.

Lea o que o paquete instalado entrega realmente antes de editar nada, incluído o seu directorio drop-in. Algunhas unidades omiten deliberadamente a baixada propia do daemon porque o xestor xa se encarga dela, e outras dependen desas opcións para o cambio posterior á inicialización. Quitar calquera das dúas sen saber que modelo herdou é a forma en que un servizo que funciona deixa de arrancar.

Escriba o modelo escollido nunha liña: propiedade do xestor ou propiedade do daemon. Cada directiva posterior debe ser coherente con esa frase, e unha unidade mixta debe tratarse como un erro e non como un compromiso.

As capacidades son límites, non concesións

Un conxunto de límites de capacidades di que pode reter un proceso como máximo. É un teito, e enumerar unha capacidade alí non concede nada por si só, por iso unha unidade cun conxunto de límites xeneroso pode aínda así non lograr crear un túnel.

O que de verdade coloca unha capacidade no conxunto ambiental dun servizo é AmbientCapabilities=. A referencia de execución de systemd documenta as dúas directivas por separado, e esa distinción explica a maior parte dos consellos confusos sobre capacidades que hai en liña.

Engada unha capacidade só despois de que a operación que falla a identifique. Un conxunto de límites máis amplo oculta a causa real e deixa o servizo máis privilexiado do que o deseño pretendía. Tamén fai a unidade máis difícil de revisar, porque o teito xa non describe o traballo. Retire a capacidade extra unha vez corrixido o fallo real.

Mapee a autoridade ao longo do ciclo de vida

Enumere que debe facer o proceso en cada etapa: arranque, estado estable, reautenticación e desmontaxe. A creación da interface, os cambios de rutas, a lectura dunha clave protexida e a invocación dun axudante non ocorren todos no mesmo momento nin cos mesmos requisitos. Ordene a lista por etapa antes de ordenala por capacidade.

As opcións de persistencia conservan recursos a través da renegociación, e non conceden permisos que nunca se tiveron. Unha clave que o proceso non pode ler ao arrancar seguirá sendo ilexible despois, digan o que digan os indicadores de persistencia. Os indicadores conservan o que xa funcionaba.

Use unha conta dedicada en lugar dunha compartida. Os desenvolvedores de OpenVPN advirten contra o costume de usar nobody como exemplo xenérico, porque outros servizos do host poden estar xa executándose con esa conta e o illamento que cre ter non está aí.

As funcións que cambian a carga local, como a descarga da canle de datos ou unha compilación que liga doutro xeito, poden desprazar que operacións fan falta. Revise o mapa cando cambie o paquete, non só cando algo se rompa.

Escriba o plan e conserve acceso de recuperación

Un rexistro de despregamento debería nomear o xestor, a identidade de arranque, a identidade estable prevista e cada concesión xunto coa operación que a require. Ese rexistro é o que fai revisable o seguinte cambio en lugar de experimental.

Manteña o acceso á consola mentres edita, porque unha unidade que falla ao arrancar é difícil de reparar en remoto. Probe un reinicio e un reinicio completo antes de dar o cambio por terminado. Unha unidade que sobrevive a un reinicio pode fallar aínda antes de que a rede estea lista.

O éxito é un ciclo de vida de autoridade mínima comprendido, non un proceso que resulta que corre baixo un nome que non é root.