Aceste comenzi nu au aceeași graniță de execuție:

proxychains4 sudo command
sudo proxychains4 command

Proxychains-ng face ca o bibliotecă să fie preîncărcată în programul țintă. Pe Linux, executarea unui program set-user-ID precum sudo declanșează regulile de securitate ale loaderului, care elimină variabilele relevante de încărcare a bibliotecilor înainte ca sudo să le poată păstra.

În consecință, „păstrarea mai multui mediu” nu este o soluție fiabilă pentru a pune sudo în interiorul wrapperului. Manualul sudoers descrie explicit că variabile precum LD_* sunt eliminate înainte ca sudo să înceapă.

Dacă o comandă chiar are nevoie de contul țintă, porniți wrapperul în acel context autorizat. Apoi verificați ce configurație citește: sudo poate schimba HOME, PATH și fișierul aplicabil pentru fiecare utilizator. O invocare fără privilegii care funcționează nu dovedește că root a ales aceeași listă de proxy.

Preferați interfața de proxy nativă a programului atunci când aceasta există. Astfel evitați să depindeți de interceptare pentru o cerere pe care programul știe deja să o dirijeze.

De asemenea, țineți cont de limitele de acoperire ale proxychains. Mesajul său de pornire dovedește că wrapperul a pornit; nu dovedește că pachetele brute, apelurile neacceptate sau un proces de aplicație existent pornit separat i-au folosit biblioteca. Confirmați operațiunea de rețea pe care intenționați să o trimiteți prin proxy, în loc să tratați privilegiul de root ca dovadă că fiecare operațiune a fost interceptată.

Articole similare