Skal du opgive chroot eller kopiere iproute2 ind i jailen?

Tjenesten starter, en klient associerer, og der dukker aldrig en rute op på serversiden. Eller daemonen nægter at starte og nævner en kommando, den ikke kunne køre. Begge udfald følger de samme tre linjer, som normalt kopieres samlet fra en hardningsguide: skift til en uprivilegeret konto, slip gruppen, og skift filsystemets root. Kun én af de tre skjuler filer, og kun én af dem fjerner rettigheden til at ændre routingtabellen. At skille dem ad er måden, du lærer, hvilken linje du egentlig vil have.

Hvad jailen fjerner, som daemonen stadig har brug for

Rootskiftet sker efter opstart, så daemonen beholder alt, hvad den allerede har åbnet, og mister alt, hvad den ville åbne senere. Enhver helper, som forbindelsen kører efter det punkt, skal findes inde i den nye root, sammen med de delte biblioteker, den indlæser. En jail bygget af en konfigurationsfil og et certifikat har ingen af delene.

At skifte til en uprivilegeret konto er en separat begrænsning. En proces, der har opgivet root, kan måske ikke ændre ruter eller bringe et interface op, selv når binærfilerne ligger lige der, så de to fejl skal diagnosticeres hver for sig.

Tre betingelser afgør, hvilken rettelse du har brug for

Den første betingelse er, hvordan dit build installerer ruter. Nyere OpenVPN udgivelser konfigurerer interface og routingtabel i processen, mens ældre pakker og egne opsætninger læner sig på eksterne værktøjer eller på up- og down-scripts. Nævner loggen en kommando, er et eksternt værktøj involveret, og jailen skjuler det. Viser loggen i stedet en tilladelsesfejl, er kontoen problemet.

Den anden er vedligeholdelse. En jail med kopierede binærfiler skal opdateres, hver gang pakken, der leverer dem, opgraderes, ellers efterlader den første opgradering en brudt tunnel. Den tredje er, om en bestemt kontrol faktisk kræver en chroot; handler kravet i virkeligheden om privilegieseparering, kan kontoskiftet alene opfylde det.

Hvad en fungerende jail skal indeholde

En jail, der kører kommandoer, har brug for binærfilerne, hvert bibliotek de linkes mod, og enhver enhedsknude, som daemonen åbner sent. Kopier delene, og test dem uden VPN i billedet:

ldd /usr/sbin/ip
chroot /etc/openvpn/jail /sbin/ip route show
chroot /etc/openvpn/jail /sbin/ip link set tun0 up

Den første kommando viser afhængighederne, og det er den, folk springer over. En kopieret binærfil, der ikke kan finde et bibliotek, fejler med en anden besked end en manglende binærfil, og begge ser ud som en OpenVPN-fejl, når de læses fra klientsiden. At køre kommandoen i jailen i hånden gengiver fejlen uden at genstarte tjenesten.

Kopier også konfigurationen, certifikaterne og en eventuel CRL ind i jailen, for en fil, som daemonen forventer at læse igen efter opstart, findes ikke, når root er skiftet. Noter, hvad du kopierede, for den næste opgradering af netværkspakken erstatter originalerne og efterlader jailen på den gamle kopi.

Skær hardningen ned i stedet

Hvis jailen kun findes, fordi en guide sagde det, er det et forsvarligt udfald at fjerne den ene linje og beholde kontobegrænsningerne. Daemonen beholder sit filsystemsyn og slipper problemet, og privilegiefaldet fjerner stadig root fra den langlivede proces.

Skriv ned, hvad der er tilbage, og hvorfor. En konfiguration, der stille mistede en kontrol uden en note, er hvordan hardning driver, og den næste revision spørger, hvorfor linjen forsvandt.

Bisektér de tre linjer, før du vælger

Kopier konfigurationen, deaktiver alle tre direktiver, og bekræft, at en klient forbinder, og at de forventede ruter vises. Genaktiver kun kontolinjerne, derefter chroot alene. Det trin, hvor tunnelen brækker, angiver grænsen, og du undgår at genopbygge en jail, som aldrig var årsagen.

Når det igen router, kør én klientsession med højere verbosity, og læs den linje, der nævner kommandoen eller den mislykkede tilladelse. Den linje er mere værd end den timeout, klienten til sidst rapporterer.