آموزش لینوکس پیشرفته؛ مدیریت، امنیت و عیب‌یابی سرور

محیط تمرین مشاهده‌ای: برای شاخهٔ AppArmor، ماشین مجازی Ubuntu 24.04 LTS یا Debian 13 با ابزار aa-status؛ برای شاخهٔ SELinux، ماشین مجازی RHEL 10 با ابزارهای sestatus و getenforce. داشتن هر دو ماشین لازم نیست؛ شاخهٔ دیگر را با سناریوی کاغذی بخوانید. دستورها وضعیت را می‌خوانند و سیاستی را بارگذاری یا خاموش نمی‌کنند. آشنایی با مجوز فایل، فرایند و گزارش سیستم پیش‌نیاز است. هدف، تشخیص شاهد مناسب هنگام خطای Permission denied است.

هویت کاربر تمامِ تصمیم دسترسی نیست

مجوزهای مالک، گروه و ACL بخشی از کنترل اختیاری یا DAC هستند. اگر برنامه‌ای با کاربر شما اجرا شود، صرفاً مجازبودن شما لزوماً به معنای مجازبودن همان برنامه برای هر منبع نیست. کنترل اجباری یا MAC لایهٔ سیاست دیگری اضافه می‌کند تا مثلاً سرویس وب فقط داده‌های تعریف‌شدهٔ خود را ببیند. SELinux و AppArmor پیاده‌سازی‌هایی در چارچوب LSM هسته‌اند. اجازهٔ یک لایه، منع لایهٔ دیگر را دور نمی‌زند؛ بنابراین 777 درمان عمومی خطای دسترسی نیست.

SELinux با context یا برچسب امنیتیِ فرایندها و منابع تصمیم می‌گیرد. در سیاست‌های رایجِ مبتنی بر type، نوع فرایند یک domain را مشخص می‌کند و قواعد، تعامل آن با نوع فایل یا منابع دیگر را کنترل می‌کنند. domain را با نام کاربر یا نام پوشه یکی نگیرید. جابه‌جایی یا ایجاد فایل ممکن است برچسبی نامناسب برای کاربرد سرویس باقی بگذارد. در RHEL، اگر DAC زودتر درخواست را رد کند، ممکن است اصلاً AVC مربوط به SELinux ثبت نشود؛ نبود AVC به‌تنهایی سلامت تمام مجوزها را ثابت نمی‌کند.

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

در نصب متعارف Ubuntu، AppArmor به‌طور پیش‌فرض نصب و بارگذاری می‌شود؛ Debian از نسخهٔ 10 آن را پیش‌فرض فعال کرده است. RHEL هنگام نصب همراه SELinux، حالت enforcing را پیش‌فرض می‌گیرد. تصویرهای کوچک، کانتینرها، هستهٔ سفارشی و تنظیم مدیر می‌توانند نتیجه را عوض کنند؛ نام توزیع جای بررسی وضعیت واقعی را نمی‌گیرد. این پیش‌فرض‌ها راهنمای انتخاب شاخهٔ تمرین‌اند، نه شاهد قطعی دربارهٔ ماشین ناشناخته.

enforcing، permissive و complain

در SELinux، enforcing سیاست را اعمال و نقض‌ها را منع می‌کند؛ permissive تصمیم‌های منع را گزارش می‌کند ولی از طرف SELinux جلویشان را نمی‌گیرد. امکان permissiveبودن domain مشخص نیز وجود دارد، پس حالت کلی تنها اطلاعات لازم نیست. در AppArmor، پروفایل enforce محدودیت را اعمال می‌کند؛ complain بیشتر نقض‌های ضمنی را برای توسعه گزارش می‌کند. complain مترادف اجازهٔ مطلق نیست: قواعد deny صریح و منعِ لایه‌های دیگر همچنان می‌توانند مؤثر باشند. نسخه‌های تازه حالت‌های بیشتری دارند؛ این دو، تمام حالت‌های ممکن در همهٔ نسخه‌ها نیستند.

# RHEL / SELinux: only if the tools exist
command -v getenforce sestatus
getenforce
sestatus

# Ubuntu or Debian / AppArmor
command -v aa-status
aa-status
printf 'aa-status exit=%s\n' "$?"

خروجی واقعی ماشین خود را ثبت کنید؛ تعداد پروفایل‌ها یا نام سیاست درسی عدد ثابتی ندارد. در sestatus، حالت فعلی را از حالت پیکربندی متمایز کنید. aa-status برای جزئیات کامل معمولاً دسترسی مدیر می‌خواهد؛ کد 4 می‌تواند کمبود مجوز و کد 3 نبود فایل‌های کنترل را نشان دهد. هیچ‌یک را فوری «حفاظت خاموش است» تعبیر نکنید. در ماشین شخصی و با دسترسی مدیریتی موجود می‌توان sudo aa-status را برای خواندن کامل اجرا کرد؛ نبود ابزار هم الزاماً نبود سازوکار هسته نیست.

تمرین: شاهد را از حدس جدا کنید

Paper scenario A — SELinux
Web worker cannot read /srv/site/index.html.
DAC and traversal permit it; a matching AVC reports a denied read.

Paper scenario B — AppArmor
An application changes its data path.
A matching profile denial names the new path.

این‌ها دادهٔ ساختگیِ مسئله‌اند، نه گزارش ماشین شما. در هر سناریو سه مورد بنویسید: کدام شاهد، فرضیهٔ MAC را تقویت می‌کند؛ کدام اطلاعات هنوز کم است؛ و کوچک‌ترین اصلاح قابل بررسی کدام است. قبل از نسبت‌دادن خطا، زمان رخداد، هویت فرایند و مسیر واقعی را با گزارش تطبیق دهید. خطای قدیمی یا گزارش فرایندی دیگر نمی‌تواند علت درخواست فعلی را به‌تنهایی اثبات کند.

پاسخ تشریحی: در A، AVC منطبق پس از تأیید DAC شاهد مهمی است؛ نوع فرایند، برچسب فعلی و برچسب مورد انتظار مسیر و قواعد مستند سرویس هنوز لازم‌اند. اصلاح پایدار باید مطابق روش برچسب‌گذاری و سیاست همان توزیع باشد. در B، مسیر جدید و نام پروفایل سرنخ‌اند؛ پروفایل بارگذاری‌شده و نیاز واقعی برنامه را تأیید می‌کنیم و قاعده‌ای محدود برای همان نیاز را بازبینی می‌کنیم. تغییر حالت کل سیستم، خاموش‌کردن حفاظت یا پذیرفتن خودکار تمام پیشنهادهای گزارش، نتیجهٔ این تشخیص نیست. هیچ تغییر سیاستی در این درس انجام نمی‌دهیم.

منابع رسمی انگلیسی:
Getting started with SELinux — Red Hat: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/using_selinux/getting-started-with-selinux
SELinux states and modes — Red Hat: https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/10/html/using_selinux/changing-selinux-states-and-modes
AppArmor — Ubuntu: https://ubuntu.com/server/docs/how-to/security/apparmor/
AppArmor HowToUse — Debian: https://wiki.debian.org/AppArmor/HowToUse
aa-status — Debian: https://manpages.debian.org/trixie/apparmor/aa-status.8.en.html

تألیف و مثال‌های اختصاصی: تحریریه درس‌آوند. منابع رسمی انگلیسی برای مطالعهٔ تکمیلی معرفی شده‌اند.