سخت‌سازی سرویس‌های systemd با sandboxing؛ 7 گام برای امنیت لینوکس

این فناوری چیست؟

systemd با sandboxing محیط اجرای سرویس را محدود می‌کند و سطح دسترسی آن را کاهش می‌دهد.

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

چرا sandboxing سرویس‌ها مهم است؟

بسیاری از سرویس‌ها با کاربر ریشه یا دسترسی گسترده اجرا می‌شوند، درحالی‌که برای کار روزمره فقط به چند مسیر، یک پورت و شاید یک دایرکتوری داده نیاز دارند. مستندات رسمی systemd گزینه‌هایی مانند ProtectSystem، ProtectHome، PrivateTmp، PrivateDevices و NoNewPrivileges را برای ساختن این مرزها ارائه می‌کند. این تنظیمات جایگزین وصله‌کردن نرم‌افزار یا کنترل دسترسی معمول لینوکس نیستند، اما یک لایهٔ دفاعی مؤثر به وجود می‌آورند.

برای مطالب آموزشی مرتبط، راهنمای مقالات فنی تکتاز را هم ببینید.

مسیر پیشنهادی برای امن‌سازی

کار را روی یک سرویس غیرحیاتی و در محیط staging شروع کنید. پیش از هر تغییر، کاربر اجراکننده، مسیرهای خواندن و نوشتن، پورت‌ها، سوکت‌ها، فایل‌های موقت و capabilityهای موردنیاز را ثبت کنید. سپس با systemctl edit نام‌سرویس یک drop-in بسازید؛ تغییر فایل اصلی unit در مسیرهای توزیع معمولاً با به‌روزرسانی بعدی از بین می‌رود.

در گام اول، سرویس را با یک کاربر کم‌اختیار اجرا کنید و NoNewPrivileges=yes را فعال کنید تا فرایند و فرزندانش نتوانند امتیاز تازه‌ای به دست آورند. بعد ProtectSystem=strict را امتحان کنید. این گزینه بخش عمدهٔ فایل‌سیستم را فقط‌خواندنی می‌کند؛ مسیرهای واقعاً لازم را با ReadWritePaths= یا گزینه‌هایی مانند StateDirectory= به‌صورت allowlist باز کنید. برای سرویس‌هایی که به خانهٔ کاربران نیاز ندارند، ProtectHome=yes و برای سرویس‌هایی که فقط باید فایل‌های محدودی را ببینند، حالت read-only مناسب‌تر است.

PrivateTmp=yes یک فضای موقت جدا می‌سازد و PrivateDevices=yes دید سرویس به دستگاه‌ها را محدود می‌کند؛ بااین‌حال هر دو ممکن است با نرم‌افزارهای قدیمی یا سرویس‌هایی که به دستگاه خاصی نیاز دارند ناسازگار باشند. گزینه‌هایی مانند ProtectProc=invisible نیز می‌توانند اطلاعات پردازش‌های دیگر را از دید سرویس پنهان کنند، اما برای سرویس‌های مانیتورینگ یا ابزارهای تشخیصی باید با دقت آزمایش شوند.

پس از هر تغییر، systemctl daemon-reload و restart کنترل‌شده انجام دهید و بلافاصله systemctl status و journalctl -u نام‌سرویس را بررسی کنید. تست واقعی مهم‌تر از سبزشدن status است: نوشتن لاگ، اتصال شبکه، خواندن تنظیمات، ساخت فایل موقت و عملیات اصلی برنامه را جداگانه امتحان کنید. سپس systemd-analyze security نام‌سرویس را قبل و بعد مقایسه کنید؛ امتیاز بهتر به‌تنهایی کافی نیست و نباید جای تست عملکرد را بگیرد.

rollback و محدودیت‌ها

drop-in را در کنترل نسخه نگه دارید تا در صورت اختلال بتوانید آن را حذف، daemon-reload و سرویس را به وضعیت قبلی برگردانید. برخی محدودیت‌ها به پشتیبانی کرنل، namespaceها، کانتینرها و نوع سرویس وابسته‌اند؛ بنابراین تنظیمی که روی یک سرور جواب می‌دهد الزاماً برای همهٔ محیط‌ها مناسب نیست. اصل عملی این است: کمترین دسترسی لازم را مرحله‌به‌مرحله اعمال کنید، هر مسیر استثنا را مستند کنید و نتیجه را با لاگ و سناریوی واقعی بسنجید.

یک الگوی عملی برای شروع

فرض کنید یک سرویس وب فقط باید فایل‌های برنامه را بخواند، در یک پوشهٔ داده بنویسد و به شبکه متصل شود. ابتدا همان سرویس را با کاربر اختصاصی اجرا کنید و مسیر داده را با StateDirectory= یا ReadWritePaths= مشخص کنید. سپس ProtectSystem=strict را اضافه کنید تا نوشتن تصادفی در مسیرهای سیستمی ممکن نباشد. اگر برنامه فایل‌های موقت می‌سازد، PrivateTmp=yes را فعال کنید و در صورت نیاز، مسیر موقت اختصاصی برنامه را مستند کنید.

در مرحلهٔ بعد، home کاربران را ببندید و دسترسی به deviceها را فقط در صورت نیاز باز کنید. سرویس وب معمولاً نباید دیسک خام، دوربین، USB یا اطلاعات پردازش‌های سایر کاربران را ببیند. برای چنین مواردی، PrivateDevices=yes و ProtectProc=invisible می‌توانند سطح مشاهده را کاهش دهند؛ اما سرویس‌های مانیتورینگ، backup و ابزارهای مدیریت سیستم ممکن است به این اطلاعات وابسته باشند. هر گزینه باید با یک تست موفق و یک تست شکست بررسی شود: هم عملکرد اصلی باید کار کند و هم تلاش برای نوشتن در مسیر ممنوع، خواندن home یا دسترسی به device غیرمجاز باید در لاگ با خطای قابل‌انتظار متوقف شود.

این رویکرد باعث می‌شود sandboxing یک تنظیم تزئینی نباشد، بلکه بخشی از چرخهٔ نگهداری سرویس شود. پیکربندی drop-in را کنار مستندات سرویس نگه دارید، دلیل هر استثنا را بنویسید و پس از به‌روزرسانی نرم‌افزار دوباره سناریوهای اصلی را اجرا کنید. به این ترتیب امنیت، قابلیت rollback و پایداری سرویس در یک روند مشترک مدیریت می‌شوند.

در systemd بهتر است هر تغییر با هدف مشخص ثبت شود: systemd برای اجرای امن سرویس، systemd برای مشاهدهٔ وضعیت و systemd برای rollback قابل‌اعتماد. این ثبت ساده کمک می‌کند تیم بداند کدام گزینهٔ systemd به کدام نیاز عملی پاسخ می‌دهد.

منبع: مستندات رسمی systemd.exec