Després de la baixada de privilegis: quins fitxers d’OpenVPN encara funcionen?

Un temps de funcionament llarg només demostra que l’arrencada va reeixir amb els privilegis que el dimoni tenia en aquell moment. Les fallades que importen aquí arriben més tard: un client nou es connecta, es substitueix una llista de revocació, un auxiliar necessita escriure un fitxer. Cadascuna és una obertura nova feta pel compte sense privilegis, amb la seva pròpia pregunta de permisos i el seu propi missatge d’error. Tres decisions separen una configuració que continua funcionant d’una que falla al proper esdeveniment.

Separeu el que es va carregar aviat del que s’obre més tard

Un descriptor és un manegament sobre una descripció de fitxer oberta, i el mode d’accés es va fixar quan es va crear aquella descripció. Canviar l’usuari del procés després no tanca el manegament, i per això un fitxer de clau llegit com a root continua funcionant després de la baixada. El mode tampoc canvia: un manegament obert per llegir no es torna escribible, i un manegament escribible no es revoca només perquè el compte hagi perdut els drets sobre el camí. Aquests dos fets expliquen la major part del comportament sorprenent d’aquests informes.

L’altra meitat és memòria. Un dimoni pot analitzar un certificat, conservar el material analitzat i tancar el fitxer; el que queda en ús són dades, no un fitxer obert. Per tant, el trànsit continu no demostra ni que hi hagi un descriptor obert ni que el nom del camí sigui abastable. Només demostra que el material necessari per a la sessió actual es va obtenir abans.

Una obertura posterior és una transacció diferent. S’executa amb les credencials actuals, el context de seguretat actual i la visió de muntatge actual, així que un camí llegible a l’arrencada pot ser refusat a la connexió següent. La rotació afegeix un parany: escriure un fitxer nou sobre el mateix nom de camí deixa un descriptor existent lligat a l’objecte antic, així que una recàrrega pot semblar reeixida mentre el dimoni encara fa servir el contingut anterior. Compareu l’inode que el procés té amb el del disc abans de creure que la rotació ha tingut efecte.

Anomeneu les tres lectures d’execució i quan es produeix cadascuna

Tres recursos s’obren normalment molt després de la inicialització, i fallen en moments diferents. Un fitxer de configuració específic d’un client es llegeix quan aquell client es connecta, així que pot trencar-se per a un usuari mentre la resta continua. Les dades de revocació es consulten durant l’autenticació d’iguals i una altra vegada quan el fitxer se substitueix. Un directori temporal només es toca quan un script o un connector hi escriu alguna cosa.

Cap dels tres no pertany al camí d’arrencada, i per això un servidor sa durant setmanes pot fallar a la connexió següent. La categoria també anomena el propietari de la solució: els dos primers són permisos de lectura sobre la configuració sota el compte del dimoni, i el tercer és una ubicació escribible amb un propòsit estret.

persist-key respon una pregunta més estreta del que la majoria de la gent suposa. Manté el fitxer de clau obert durant els reinicis documentats de SIGUSR1 i ping-restart, i no fa res per als fitxers CCD, les dades de revocació, els executables auxiliars o un reinici complet del procés. Aquests segueixen els seus propis camins d’obertura, sota el compte que hi hagi en aquell moment.

Confirmeu el compte i la visió que realment té

Pregunteu al dimoni en funcionament quin compte fa servir en lloc de confiar en el fitxer d’unitat, i després compareu la resposta amb el que la unitat estableix. Una discrepància és la primera cosa a resoldre, perquè cada comprovació de permisos posterior s’executa com qui és realment el procés. Després recorreu el camí component a component; el travessament s’avalua a cada nivell, així que un fitxer llegible dins d’un directori no travessable continua sense ser llegible. El mode final del fitxer és la darrera pregunta, no la primera.

Els espais de noms i les caixes de sorra de servei afegeixen fronteres que la propietat i els bits de mode no descriuen. Un camí visible a la vostra shell pot ser absent o de només lectura dins d’un chroot, un espai de noms de muntatge o una unitat que amaga els directoris personals. Els mòduls de seguretat afegeixen una capa més, així que un fitxer que sembla llegible encara pot ser denegat quan s’obre.

ps -o user:12,pid,args -C openvpn
systemctl show -p User -p Group -p ProtectHome -p RootDirectory [email protected]
sudo -u openvpn namei -l /etc/openvpn/ccd/alice

Una lectura correcta a la shell de l’administrador no comprova cap d’aquestes condicions combinades. Executeu la comprovació amb el compte del dimoni, amb el mateix espai de noms i la mateixa caixa de sorra, o accepteu que el resultat descriu la vostra shell i no el servidor. La tercera ordre és la versió barata d’aquesta prova: imprimeix el mode de cada component i falla al primer que el compte del dimoni no pot travessar.

Concediu l’escriptura d’execució en un directori propi

La lectura és només la meitat de l’inventari. Un script auxiliar pot necessitar crear un fitxer d’estat, un connector pot necessitar escriure estat al costat de la seva configuració, i aquestes escriptures no queden cobertes per fer escribible l’arbre de configuració. Doneu al directori concret el permís d’escriptura que la seva funció necessita, amb un propietari i un mode que pugueu explicar. Preferiu l’accés de només lectura per a tot el que només es llegeix.

Mantingueu els permisos de la clau privada separats dels fitxers de política. Una clau que s’ha de rellegir després d’un reinici té un requisit diferent d’un fitxer de client llegit a cada connexió, i un sol mode permissiu per als dos atorga més accés del que demana el problema. Un compte de dimoni dedicat amb propietat estreta és més fàcil d’auditar que un grup ampli. Quan la clau ha de sobreviure als reinicis, persist-key elimina la relectura en lloc d’ampliar el directori.

Decidiu a partir de l’esdeveniment que podeu reproduir

Un túnel actiu demostra un sol camí pel codi. L’esdeveniment que necessita el fitxer és l’únic test que cobreix l’obertura que us importa, ja sigui una connexió de client nova, un fitxer de revocació substituït, un reinici suau permès o un reinici planificat. Trieu l’esdeveniment, executeu-lo i quedeu-vos amb el primer error i no amb el darrer.

Per a un reinici suau, un senyal i el registre de la unitat mostren si la clau s’ha llegit una altra vegada. Envieu el senyal i després llegiu les darreres línies que la unitat ha escrit:

systemctl kill -s SIGUSR1 [email protected]
journalctl -u [email protected] -n 40 --no-pager

No concloeu que un dimoni compromès ja no pot modificar fitxers només perquè s’han baixat els privilegis. El que encara pot fer depèn de les credencials que li queden, de les seves capacitats, dels directoris on pot escriure i de qualsevol descriptor escribible que encara tingui. La reducció de privilegis estreny l’autoritat, i l’inventari d’obertures d’execució és el que mostra fins on. Escriviu aquesta frontera al costat de la configuració perquè la propera persona no l’hagi de redescobrir.