سخت‌سازی سرویس‌های systemd با آزمون و بازگشت امن

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

مسیر پیش‌فرض برای Ubuntu 26.10 بررسی شده است؛ گزینه‌های 26.04 LTS و 24.04 LTS نیز در دسترس‌اند. بسته‌ها را با همان انتشار و پیکربندی واقعی میزبان تطبیق دهید.

آزمایش mount و مجوز فایل، کنترل مستقل SELinux یا AppArmor را حذف نمی‌کند. روی Ubuntu و Debian لاگ denial پروفایل‌های فعال را با زمان خطا تطبیق دهید. روی RPM، مالکیت و برچسب مسیر state و AVC مربوط به همان سرویس را بررسی کنید؛ برای آزمایش sandbox، SELinux را permissive نکنید. امتیاز exposure نیز تأیید امنیت برنامه نیست.

cat /etc/os-release
dpkg-query -W systemd coreutils
command -v systemctl systemd-run systemd-analyze

روی میزبان آزمایشی، unit و drop-inهای مؤثر example-app.service را بخوانید. کاربر اجرا، مسیرهای نوشتنی، سوکت‌ها، دستگاه‌ها، خانواده‌های آدرس و helperهای لازم را مشخص کنید. فایل unit ممکن است مقدار خصوصی داشته باشد؛ خروجی کاملش را عمومی نکنید.

یک تنظیم برای همهٔ برنامه‌ها مناسب نیست. برای مثال، محدودیت حافظهٔ قابل اجرا می‌تواند runtime دارای JIT را از کار بیندازد. امتیاز فعلی را فقط به‌عنوان شاهد پیکربندی نگه دارید.

systemd --version
sudo systemctl cat 'example-app.service'
sudo systemctl show 'example-app.service' -p User -p Group -p FragmentPath -p DropInPaths -p MainPID -p ProtectSystem -p ReadWritePaths
sudo systemd-analyze security 'example-app.service'

لاگ کرنل را در بازهٔ زمانی همان خطا بررسی کنید. روی میزبان دارای AppArmor، denial پروفایل فعال ممکن است مستقل از مجوز Unix یا شبکه باشد؛ پروفایل را صرفاً برای سبزشدن تست خاموش نکنید. این بررسی جای لاگ برنامه و بررسی سیاست واقعی میزبان را نمی‌گیرد.

sudo journalctl -k --since '-10 min' --no-pager -n 120

/var/lib/academy-sandbox-lab نباید دادهٔ برنامه، symlink یا مسیر mountشدهٔ سرویس عملیاتی باشد. اگر از قبل وجود دارد متوقف شوید. یک شاخهٔ خصوصی و زیرشاخهٔ state می‌سازیم و نشان می‌دهیم root در حالت عادی می‌تواند در والد بنویسد.

سرویس آزمایش بعدی عمداً root است تا منع ناشی از mount را با مالکیت معمول Unix اشتباه نگیریم. این انتخاب برای تفکیک آزمایش است؛ پیشنهاد اجرای برنامهٔ واقعی با root نیست.

sudo test ! -e '/var/lib/academy-sandbox-lab' || exit 1
sudo mkdir -m 0700 -- '/var/lib/academy-sandbox-lab' || exit 1
sudo mkdir -m 0700 -- '/var/lib/academy-sandbox-lab/state'
sudo sh -c 'printf control > "$1/control-before"' sh '/var/lib/academy-sandbox-lab'
sudo stat -c '%U %G %a %n' '/var/lib/academy-sandbox-lab' '/var/lib/academy-sandbox-lab/control-before'

نام سرویس موقت باید آزاد باشد. فرایند آزمایش در namespace خودش فایل‌سیستم را فقط‌خواندنی می‌بیند و فقط state آزمایش برایش نوشتنی است. نوشتن در والد باید با خطایی مانند read-only filesystem رد شود؛ نوشتن در state باید موفق شود.

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

test "$(systemctl show -p LoadState --value 'example-app-academy-mount-probe.service')" = not-found || exit 1
sudo systemd-run --wait --pipe --collect --unit='example-app-academy-mount-probe' --property=Type=oneshot --property=ProtectSystem=strict --property='ReadWritePaths=/var/lib/academy-sandbox-lab/state' --property=NoNewPrivileges=yes --property=PrivateTmp=yes /bin/sh -c 'if touch "$1/forbidden-inside"; then echo UNEXPECTED_WRITE; exit 1; fi; printf allowed > "$1/state/allowed-inside"; test -s "$1/state/allowed-inside" || exit 1; echo ALLOWED_STATE_WRITE' sh '/var/lib/academy-sandbox-lab'