چرا nosuid اجازه نمی‌دهد کمک‌کننده VPN به root تبدیل شود
پوشه خانگی رمزگذاری‌شده و سوار کردن با nosuid دو ویژگی متفاوت‌اند. کمک‌کننده به مسیر نصب قابل‌اعتماد و بافتی برای اجرا نیاز دارد که بیت امتیاز آن را محترم بشمارد.
رمزگذاری دیسک و سوار کردن با nosuid شبیه دو گونه از یک ایده به گوش می‌رسند، و هیچ ارتباطی با هم ندارند. یکی از داده‌های در حال استراحت محافظت می‌کند و دیگری تصمیم می‌گیرد که آیا هسته در لحظه آغاز یک برنامه بیت امتیاز را محترم می‌شمارد یا نه. کمک‌کننده‌ای که به هویتی که انتظار دارد نمی‌رسد، از دومی شکایت دارد. این فرض که اولی مسئول است، مردم را به نصب دوباره کارخواهانی می‌فرستد که هرگز خراب نبوده‌اند.
دو ویژگی بی‌ارتباط
رمزگذاری دیسک پاسخ می‌دهد که وقتی ماشین خاموش است چه کسی می‌تواند بلوک‌ها را بخواند. گزینه سوار کردن پاسخ می‌دهد که هسته وقتی کسی فایلی را اجرا می‌کند با بیت‌های حالت آن چه می‌کند. هیچ چیز در اولی دومی را محدود نمی‌کند و یک لپ‌تاپ کاملاً رمزگذاری‌شده می‌تواند سامانه‌ای پرونده‌ای را با همه محدودیت‌ها سوار کند.
خواندن آن دو به‌عنوان یک ویژگی همان چیزی است که این نظریه را می‌سازد که پوشه خانگی رمزگذاری‌شده مانع دسترسی root می‌شود. آن نظریه می‌ماند چون دو نشانه روی یک ماشین ظاهر می‌شوند، نه چون علت مشترکی دارند.
واقعاً چه چیزی آن گذار را سرکوب می‌کند
مرجع execve توضیح می‌دهد که چگونه یک فایل اجرایی با set-user-ID هویت مؤثر فرایند جدید را به مالک فایل تغییر می‌دهد. همان صفحه شرط‌هایی را فهرست می‌کند که آن گذار را سرکوب می‌کنند و معادل آن را برای شناسه‌های گروه: تنظیم no_new_privs، سامانه پرونده‌ای که با nosuid سوار شده و فرایندی که ردیابی می‌شود. توانایی‌های فایل در همان شرایط نادیده گرفته می‌شوند. آن چهار قاعده تقریباً هر گزارش از این نوع را پوشش می‌دهد.
آن فهرست توضیح می‌دهد که چرا حالتی که ls چاپ می‌کند هرگز تمام داستان مجوزدهی نیست. به شما نمی‌گوید کدام شرط یک پیام خطای مشخص را ایجاد کرده، و ممکن است برنامه عملیاتی نامرتبط با اعتبارنامه را با همان واژه‌ها گزارش کند. پیش از نتیجه‌گیری، برنامه دقیق، راه‌انداز و توالی خطا را ثبت کنید.
فایل اجرایی‌ای را که بسته پشتیبانی‌شده نصب کرده، مالک آن، مسیر واقعی آن و سیاست سامانه پرونده‌ای که آن را نگه می‌دارد مشخص کنید. نسخه‌ای که در پوشه بارگیری‌ها نشسته، کمک‌کننده نصب‌شده نیست، هر چه حالت آن بگوید.
چه کاری نباید کرد
گذاشتن بیت‌های set-user-ID روی یک باینری تأییدنشده و جابه‌جا کردن آن تا وقتی محدودیت ناپدید شود، تعمیر نیست. این سیاستی را که نفهمیده‌اید با امتیازی جایگزین می‌کند که نمی‌توانید حسابرسی کنید، و همان تکنیک روی یک کمک‌کننده مسیر افزایش امتیاز شناخته‌شده‌ای است. برداشتن nosuid از یک سوارگاه بدتر است، چون روی هر برنامه در آن سامانه پرونده اثر می‌گذارد، نه فقط یکی.
مسیر پشتیبانی‌شده همان نصب مستند کمک‌کننده یا سرویس از سوی کارخواه است که یک مدیر آن را انجام می‌دهد و باینری را همان‌جا می‌گذارد که سیاست انتظار دارد. این‌گونه یک سازوکار امتیاز می‌ماند نه دو تا.
بافت واقعی اجرا را تأیید کنید
پس از یک اصلاح مجاز، کمک‌کننده را همان‌گونه که محصول اجرا می‌کند اجرا کنید، نه از یک شل root. موفقیت به‌عنوان root چیزی درباره مسیری که کاربر عادی می‌رود ثابت نمی‌کند، و تفاوت میان این دو بافت دقیقاً همان چیزی است که شکست درباره آن بود.
سپس عملیات شبکه‌ای را که کمک‌کننده برای آن وجود دارد تأیید کنید. کمک‌کننده‌ای که آغاز می‌شود ولی نمی‌تواند رابط را پیکربندی کند مشکل را یک مرحله جلوتر برده است، نه حل کرده.
findmnt -no TARGET,OPTIONS /home
getcap /usr/libexec/openvpn-helper 2>/dev/null; ls -l /usr/libexec/openvpn-helperگزینه‌های سوار کردن و مالکیت کمک‌کننده را در همان یادداشت ثبت کنید. وگرنه نفر بعدی که این را اشکال‌زدایی می‌کند نظریه رمزگذاری را از آغاز تکرار خواهد کرد.