Puncte:3

Server OpenVPN - renunțarea la privilegii afectează accesarea fișierelor în timpul execuției?

drapel ck

În Articolul de întărire al OpenVPN, se recomandă ca daemonul server să renunțe la privilegiile după pornirea pe Linux:

OpenVPN a fost proiectat foarte atent pentru a permite renunțarea la privilegiile root după inițializare, iar această caracteristică ar trebui să fie întotdeauna utilizată pe Linux/BSD/Solaris. Fără privilegii de rădăcină, un daemon de server OpenVPN care rulează oferă o țintă mult mai puțin atrăgătoare unui atacator.

Aceștia recomandă stabilirea următoarelor directive:

utilizator nimeni
grupa pe nimeni

ceea ce presupun că înseamnă că demonul va rula ca nimeni după ce pornirea este completă.

Cu toate acestea, există mai multe fișiere pe care OpenVPN le accesează în timpul execuției, în special fișierul CRL:

Când opțiunea crl-verify este utilizată în OpenVPN, fișierul CRL va fi recitit de fiecare dată când un client nou se conectează sau un client existent renegociază conexiunea SSL/TLS (în mod implicit o dată pe oră). Aceasta înseamnă că puteți actualiza fișierul CRL în timp ce demonul serverului OpenVPN rulează și ca noul CRL să intre în vigoare imediat pentru clienții nou conectați.

Deci, firește, îmi fac griji dacă aceste două caracteristici sunt incompatibile - dacă demonul renunță la privilegii după pornire, cum poate citi /etc/openvpn/server/crl.pem (proprietar rădăcină:rădăcină, modul 0600; Aplicarea SELinux) în timpul rulării?

  • Dacă demonul într-adevăr nu poate accesa fișierul CRL în timpul execuției, există o modalitate bună de a evita această problemă?
  • Dacă demonul poate accesa fișierele CRL în timpul execuției, aș dori să știu cum este posibil acest lucru.

Sistemul de operare este RHEL8.5 x86_64 în cazul în care este relevant.

Puncte:2
drapel et

La fel ca multe aplicații care renunță la privilegii, OpenVPN deschide diverse mânere de fișiere cât mai are root, care apoi persistă. Odată ce a renunțat la confidențialitate, procesul este încă capabil să acceseze acele mânere în modul în care au fost deschise, atâta timp cât rămân deschise.

Un compromis al openvpn procesul nu ar expune fișierul la modificări în acest caz, deoarece fișierul este (probabil, nu l-am verificat) deschis doar în citire. Ar fi necesar un nou handle de fișier pentru a-l deschide în modul de scriere, care ar eșua deoarece procesul nu mai poate crea unul.

cyqsimon avatar
drapel ck
Ah multumesc. Are sens.Există o sursă oficială în care este documentat acest comportament? Sau este acest comportament atât de banal încât a devenit în esență idiomatic și nu merită documentat?
drapel et
Presupun că singura sursă _oficială_ este codul sursă real, deoarece este singurul tău ghid adevărat pentru ceea ce se întâmplă cu adevărat. Dacă doriți să _înțelegeți_ mai multe, atunci poate începeți cu paginile wiki/man de pe [descriptori de fișiere](https://en.wikipedia.org/wiki/File_descriptor) și cu [apelul de sistem open()](https: //man7.org/linux/man-pages/man2/open.2.html). Odată ce v-ați dat seama că se efectuează verificări ale permisiunilor _la acele apeluri de sistem_, totul are mai mult sens :)
drapel my
Renunțarea la privs după deschiderea porturilor private este cu siguranță o bună practică larg răspândită pentru demonii vechi *nix precum openvpn și bind. Nu sunt sigur de o referință autorizată pentru acest obicei.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.