sudo proxychains מול proxychains sudo: מדוע הסדר חשוב
הבינו מדוע proxychains sudo עלול לאבד את ספריית היירוט שלו, בעוד sudo proxychains מפעיל את העטיפה בהקשר ההרצה של היעד.
לפקודות האלה אין אותה גבול הרצה:
proxychains4 sudo command
sudo proxychains4 command
Proxychains-ng דואג שספרייה תיטען מראש לתוך תוכנית היעד. בלינוקס, הרצת תוכנית עם set-user-ID כמו sudo מפעילה את כללי האבטחה של הטוען, שמסירים את משתני טעינת הספריות הרלוונטיים לפני ש-sudo יכול לשמור עליהם.
לכן, «שמירה על יותר סביבה» אינה תיקון מהימן להכנסת sudo לתוך העטיפה. מדריך sudoers מתאר במפורש שמשתנים כמו LD_* מוסרים לפני ש-sudo מתחיל.
אם פקודה באמת דורשת את חשבון היעד, הפעילו את העטיפה בהקשר המורשה הזה. לאחר מכן בדקו איזו תצורה היא קוראת: sudo עשוי לשנות את HOME, את PATH ואת הקובץ הרלוונטי לכל משתמש. קריאה לא־מורשית שעובדת אינה מוכיחה ש-root בחר באותה רשימת פרוקסי.
העדיפו את ממשק הפרוקסי המקורי של התוכנית כשהוא קיים. כך נמנעים מתלות ביירוט עבור בקשה שהתוכנית כבר יודעת לנתב.
זכרו גם את מגבלות הכיסוי של proxychains. הודעת ההפעלה שלו מוכיחה שהעטיפה התחילה; היא אינה מוכיחה שחבילות גולמיות, קריאות לא נתמכות או תהליך יישום קיים שהופעל בנפרד השתמשו בספרייה שלו. אשרו את פעולת הרשת שרציתם ליירט, במקום לראות בהרשאת root הוכחה לכך שכל פעולה יורטה.