سخت‌سازی systemd را روی افت user در OpenVPN لایه‌بندی نکنید

دو دستور کمترین امتیاز که کنار هم چسبانده شوند، استقرار سخت‌گیرانه‌تری نمی‌سازند. یک مدل می‌گذارد دیمن با امتیاز آغاز شود و پس از راه‌اندازی به حسابی بی‌امتیاز فرو بیاید؛ مدل دیگر می‌گذارد مدیر سرویس آن را از نخستین دستور زیر هویتی محدود اجرا کند. هر یک به‌تنهایی کار می‌کند و ترکیب آن‌ها اغلب سرویسی می‌سازد که هیچ‌یک از دو کار را پاکیزه انجام نمی‌دهد. بقیه این نوشته تصمیم را به ترتیب می‌پیماید.

دو مدل، یک مالک برای تغییر

مدل نخست از آنِ دیمن است. گزینه‌های OpenVPN در نسخه جامعه user و group هویت را پس از برپایی تونل و کلیدها تغییر می‌دهند و persist-key همراه با persist-tun آن منابع را پس از آن قابل استفاده نگه می‌دارند.

مدل دوم از آنِ مدیر سرویس است. تنظیم systemd User= یا Group= هویتی را تعیین می‌کند که فرایند زیر آن آغاز می‌شود و دستورهای توانایی تعیین می‌کنند چه چیزهایی می‌تواند نگه دارد. انتخاب میان مدل‌ها پرسشی بسته‌بندی است پیش از آنکه پرسشی امنیتی باشد و نگهدارنده بسته پیش‌تر به آن پاسخ داده است. کار شما یافتن آن پاسخ است، نه ساختن گزینه‌ای سوم.

هر دو مشروع‌اند. خطا این است که آن‌ها را لایه‌های یک طراحی بدانیم، چون مدل دوم می‌تواند تغییر هویت مدل نخست را به عملی تبدیل کند که فرایند دیگر اجازه انجامش را ندارد.

تعیین کنید هویت کجا تغییر می‌کند

اگر واحد از پیش به‌عنوان حسابی اختصاصی آغاز شود، افزودن دستوری به دیمن برای رفتن به حسابی دیگر، گذار setuid می‌طلبد که سرویس سخت‌شده هرگز برای آن ساخته نشده بود. شکست به‌صورت خطای دسترسی در آغاز ظاهر می‌شود، نه پیام روشن سیاست. این مثل توانایی گم‌شده خوانده می‌شود و مردم را به سوی مجموعه مرزهای گسترده‌تر می‌فرستد، نه به سوی پرسش هویت.

پیش از ویرایش هر چیز، بخوانید بسته نصب‌شده واقعاً چه چیزی می‌آورد، از جمله پوشه drop-in آن. برخی واحدها عمداً افت دیمن را حذف می‌کنند چون مدیر از پیش آن را اداره می‌کند و برخی برای تغییر پس از راه‌اندازی به همان گزینه‌ها تکیه دارند. برداشتن هر یک از این دو بدون دانستن اینکه کدام مدل را به ارث برده‌اید، همان راهی است که سرویسی کارآمد از آغاز به کار می‌ایستد.

مدل برگزیده را در یک خط بنویسید: متعلق به مدیر یا متعلق به دیمن. هر دستور بعدی باید با آن جمله سازگار باشد و واحد آمیخته را باید ایراد شمرد، نه سازش.

توانایی‌ها مرزند، نه بخشش

مجموعه مرز توانایی می‌گوید فرایند حداکثر چه چیزهایی می‌تواند نگه دارد. این سقفی است و برشمردن یک توانایی در آن به‌خودی‌خود چیزی نمی‌بخشد، از این‌رو واحدی با مجموعه مرز سخاوتمندانه باز هم ممکن است نتواند تونل بسازد.

آنچه واقعاً توانایی را در مجموعه پیرامونی یک سرویس می‌گذارد AmbientCapabilities= است. مرجع اجرای systemd این دو دستور را جدا مستند می‌کند و همین تمایز بیشتر توصیه‌های گیج‌کننده درباره توانایی در اینترنت را توضیح می‌دهد.

توانایی را تنها پس از آنکه عملیات ناکام آن را شناسایی کرد بیفزایید. مجموعه مرز گسترده‌تر علت واقعی را پنهان می‌کند و سرویس را امتیازدارتر از آنچه طراحی می‌خواست باقی می‌گذارد. همچنین بازبینی واحد را سخت‌تر می‌کند، چون سقف دیگر کار را توصیف نمی‌کند. پس از رفع ایراد واقعی، توانایی اضافی را بردارید.

اختیار را در سراسر چرخه عمر نگاشت کنید

فهرست کنید فرایند در هر مرحله چه باید بکند: آغاز، حالت پایدار، احراز هویت دوباره و برچیدن. ساختن رابط، تغییر مسیرها، خواندن کلید محافظت‌شده و فراخوانی یک کمک‌کننده همه در یک لحظه یا با یک نیاز رخ نمی‌دهند. فهرست را پیش از مرتب‌کردن بر پایه توانایی، بر پایه مرحله مرتب کنید.

گزینه‌های ماندگاری منابع را در بازمذاکره حفظ می‌کنند و اجازه‌هایی که هرگز نداشته‌اند نمی‌دهند. کلیدی که فرایند در آغاز نمی‌تواند بخواند، بعد هم ناخواندنی می‌ماند، هر چه پرچم‌های ماندگاری بگویند. پرچم‌ها آنچه از پیش کار می‌کرد را حفظ می‌کنند.

از حسابی اختصاصی استفاده کنید، نه حسابی مشترک. توسعه‌دهندگان OpenVPN از عادت به کار بردن nobody به‌عنوان نمونه‌ای عمومی برحذر می‌دارند، چون دیگر سرویس‌های میزبان ممکن است از پیش با آن حساب اجرا شوند و جداسازی‌ای که گمان می‌کنید دارید وجود ندارد.

ویژگی‌هایی که بار کاری محلی را تغییر می‌دهند، مانند بارزدایی کانال داده یا ساختی با پیوند متفاوت، می‌توانند جابه‌جا کنند که چه عملیاتی لازم است. هرگاه بسته تغییر کرد نگاشت را بازبینی کنید، نه فقط وقتی چیزی می‌شکند.

برنامه را بنویسید و دسترسی بازیابی را نگه دارید

سند استقرار باید مدیر، هویت آغاز، هویت پایدار مقصود و هر بخشش را همراه با عملیاتی که آن را می‌طلبد نام ببرد. همان سند است که تغییر بعدی را بازبینی‌پذیر می‌کند، نه آزمایشی.

هنگام ویرایش دسترسی کنسول را در دسترس نگه دارید، چون واحدی که در آغاز شکست می‌خورد از راه دور سخت تعمیر می‌شود. پیش از آنکه تغییر را تمام بدانید، یک راه‌اندازی دوباره و یک بوت کامل را بیازمایید. واحدی که از راه‌اندازی دوباره جان به در می‌برد باز هم می‌تواند پیش از بالا آمدن شبکه شکست بخورد.

موفقیت چرخه عمری است با کمترین اختیار که فهمیده شده باشد، نه فرایندی که تصادفاً زیر نامی غیر از root اجرا می‌شود.