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

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

در RHEL، مخزن‌های مجاز همان اشتراک و در Rocky Linux و AlmaLinux، مخزن‌های رسمی همان نسخه لازم‌اند. نسخهٔ فرعیِ تحت پشتیبانی را به‌روز نگه دارید؛ انتخاب نسخهٔ اصلی به معنی سازگاری تمام بسته‌های قدیمی یا سفارشی نیست. SELinux و سیاست رمزنگاری سیستم بخشی از محیط‌اند و برای عبور از خطا خاموش نمی‌شوند.

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

cat /etc/os-release
rpm -q 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'

هم‌زمان با خطای ثبت‌شده، denial مربوط به فرایند و مسیر دقیق را پیدا کنید. نبود AVC یا شکست ابزار، به‌تنهایی SELinux را از بررسی خارج نمی‌کند. برچسب، دامنهٔ فرایند و سیاست نصب‌شده را بررسی کنید؛ این گام مجوز جدید تولید نمی‌کند و SELinux خاموش نمی‌شود. بررسی restorecon در این پنل فقط پیش‌نمایش است و برچسب را تغییر نمی‌دهد. مجوز Unix، برچسب SELinux و ReadWritePaths سه بررسی جدا هستند؛ هر سه باید با کاربرد واقعی مسیر state سازگار باشند.

getenforce
sudo ausearch -m AVC,USER_AVC -ts recent
ls -Zd '/var/lib/example-app'
sudo restorecon -nRv '/var/lib/example-app'

/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'