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

رابط، سازوکار و بررسی

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

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

سپردن کار، طراحی عادی است

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

NetworkManager نمونه‌ی مشخص در لینوکس است. راهنمای پیکربندی آن توضیح می‌دهد که PolicyKit چگونه در تنظیم پیش‌فرض به درخواست‌های غیر root مجوز می‌دهد. این مجوزدهی سپرده‌شده را در یک محصول واقعی نشان می‌دهد. اثبات نمی‌کند که هر کارخواه تجاری از NetworkManager استفاده می‌کند و مسیر سوکت یا سیاست هیچ فروشنده‌ی خاصی را توصیف نمی‌کند.

الگو، سپردن کار همراه با سیاستی در پس آن است. مثال یک پیاده‌سازی از این الگو است، نه پیاده‌سازی جهانی.

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

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

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

systemctl status NetworkManager
nmcli general permissions
ls -l /run/NetworkManager

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

اجازه‌ها را به روش پشتیبانی‌شده اصلاح کنید

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

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

جداسازی خوب چگونه است

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

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

مقالات مرتبط