Zerbitzua abiatzen da, erregistroak tun gailua ireki ezin duela kexatzen du, eta ibilbideak ez dira inoiz agertzen. Exekutatu capsh --print zure shellean eta cap_net_admin han bertan dago, eta horrek hutsegitea ezinezkoa dirudiela eragiten du. Zure shellaren eta unitatearen arteko aldea privilegioen trantsizioa da, ez kernelak gaitasuna emateko duen borondatea. Egin beheko lau egiaztapenak ordenan eta gelditu aldea azaltzen duen lehenengoan.

Bereizi falta den gaitasuna gailu ezkutu batetik

Hutsegite bi berdin ikusten dira erregistro-lerrotik. CAP_NET_ADMIN gabe prozesu batek ezin du tunelaren interfazea sortu edo konfiguratu, eta sandboxak /dev/net/tun ezkutatzen dion prozesu batek ezin du hasieratik ireki. Gaitasunak gehitzeak ez du bigarren kasua konponduko.

Egiaztatu gailua zerbitzuaren izen-espazioan badagoen, ezer editatu aurretik. PrivateDevices=yes ohiko gogortze-lerroa da, tun nodoa erabat kentzen duena, eta ProtectSystem murriztaileak konfigurazio-bidea irakurketa hutsekoa bihur dezake baimen-errore gisa irakurtzen den moduan. Biek tunela aipatzen duten erregistro-lerroak sortzen dituzte, eta horregatik gaitasunei leporatzen zaie. Egiaztatu lehenik nodoa badagoela eta ireki daitekeela, eta gero jarraitu.

Jakin zein gaitasun-multzo ari zaren begiratzen

Linuxek baimendutako, eraginkorreko, heredatzeko, mugatzeko eta inguruneko multzoak gordetzen ditu, eta inguruneko multzoa da root ez den erabiltzaile baten exec-aren ondoren bizirik irauten duena. Bitarreko fitxategi-gaitasunek baimendutako eta eraginkorreko eskubideak eman ditzakete exec-ean, baina katean ezerk transferentzia hori blokeatzen ez duen bitartean soilik.

Hemen nahasten ditu sudo-k pertsonak. sudo -u bidez exekutatutako komando batek privilegio-trantsizio berria hasten du eta inguruneko multzoa desagertu egiten da, beraz root gisa arrakasta duen egiaztapen berak han huts egiten du. Zerbitzu-kudeatzailea beste trantsizio bat da, eta ez du inguruneko ezer ematen unitateak hori esaten ez badu.

Eman gaitasuna unitatean, ez bilgarri batean

Gailu bat sortu eta ibilbideak instalatu behar dituen tunel baterako zerbitzu-atal minimoa horrela irakurtzen da.

[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-k eskubidea inguruneko multzoan jartzen du prozesua abiatu aurretik, eta CapabilityBoundingSet-k prozesuak zerrenda horretatik kanpo ezer ez edukitzea eragozten du. NoNewPrivileges=yes-k setuid edo fitxategi-gaitasunen bidez privilegioak lortzea blokeatzen du, unitateak berariaz ematen duen gaitasuna oraindik ere aplikatzen den bitartean. Gehitu CAP_NET_BIND_SERVICE zerbitzuak portu baxu bat lotu behar duenean soilik, eta inoiz ez gehitu CAP_SYS_ADMIN foro-hari batek egin duelako.

Unitateak bitarra sudo barruan biltzen badu, kendu bilgarria. systemd-ek jada User= aplikatzen du, eta geruza gehigarri hori da inguruneko multzoa hutsik egoteko arrazoi probableena.

Egiaztatu prozesu biziaren aurka, ez unitate-fitxategiaren aurka

Irakurri kudeatzaileak benetan zer aplikatu duen, eta gero irakurri sortu duen prozesua.

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

Unitateak gaitasuna zerrendatzen badu eta CapEff-k oraindik ez badu, drop-in batek ezarpena gainidazten du edo ExecStartPre urrats batek ingurunea aldatzen du. Bilatu unitatearen izena drop-in direktorioetan fitxategi nagusia autoritatea dela suposatu aurretik, geroagoko fitxategi batek isilpean irabazten baitu. Unitateak eta prozesuak gaitasuna erakusten badute eta tunelak oraindik huts egiten badu, itzuli gailu- eta bide-egiaztapenetara multzo mugatzailea zabaldu beharrean. Hura zabaltzeak benetako kausa ezkutatzen du eta zerbitzua lehen baino pribilegiatuago uzten du.

Hobetsi privilegioak abiatu ondoren uztea

OpenVPN privilegiatuta hasi eta gero bere user eta group aukeren bidez privilegiorik gabeko kontu batera jaits daiteke, persist-key eta persist-tun tunela gero erabilgarri mantenduz. Antolamendu horrek prozesuak eskubideak dituen leihoa estutzen du, eta askotan egokiagoa da deabru osoa privilegiorik gabe gaitasun iraunkorrekin abiatzea baino.

Aukeratzen duzun eredua edozein dela ere, berrabiarazi unitatea eta errepikatu egiaztapenak berrabiarazpen baten ondoren, root shell interaktibo batetik funtzionatzen duen eta abiaraztean huts egiten duen zerbitzu bat normalean gaitasun, gailu edo fitxategi-baimenen aldea delako. Idatzi unitatearen ezarpenak prozesuaren gaitasun-irteeraren ondoan, hurrengo berrikusleak ikus dezan pakete-eguneratze batek edo drop-in batek muga mugitu duen.

Erlazionatutako artikuluak