مجوزها در لینوکس به پرسش «چه کسی میتواند این فایل را بخواند» پاسخ میدهند. AppArmor به پرسشی دیگر پاسخ میدهد: «این برنامه اصلاً اجازه چه کاری را دارد». و تفاوت هنگام نفوذ آشکار میشود. وبشل با حساب کاربر وبسرور اجرا میشود و همه حقوق او را به ارث میبرد — و این یعنی دسترسی خواندن به نیمی از سامانه. پروفایل AppArmor فرایند را به فهرست آنچه برای کارش لازم دارد محدود میکند، و تلاش برای خواندن /etc/shadow یا اجرای /bin/bash بیتوجه به مجوزهای کاربر با رد پایان مییابد.
چه چیزی از پیش فعال است
sudo aa-statusخروجی به سه پرسش پاسخ میدهد: چند پروفایل بار شده، چند تای آنها در حالت enforce و چند تا در complainاند، و کدام فرایندها بیهیچ پروفایلی اجرا میشوند. روی یک Ubuntu معمول چند ده پروفایل خواهد بود، اما تقریباً همهشان برای برنامههای کمکی مانند man و tcpdump هستند. و سرویسهای کلیدی — nginx، Apache، PHP-FPM — معمولاً در فهرست محدودشدهها نیستند.
سه حالت که ارزش تمیزدادن دارند:
- enforce — قواعد اعمال میشوند و هر چیز اضافی رد میشود؛
- complain — تخلفها تنها در ژورنال ثبت میشوند و چیزی مسدود نمیشود. حالت تنظیم؛
- unconfined — پروفایلی نیست و برنامه بیمحدودیت اجرا میشود.
سودمندترین بخش خروجی aa-status بخش پایانی آن است: فرایندهایی که به شبکه گوش میدهند و هیچ چیزی محدودشان نمیکند. و از همین فهرست آغاز میکنند.
ابزارها
sudo apt install apparmor-utilsبدون این بسته فرمانهای aa-complain و aa-enforce و aa-logprof در سامانه نیستند، هرچند خود AppArmor کار میکند.
چگونه پروفایلی را بدون ایستاندن سرویس فعال کنیم
ترتیب اینجا بنیادی است. پروفایلی که یکراست به enforce برده شود به احتمال زیاد چیزی را که سرویس لازم دارد رد خواهد کرد و سرویس از کار میافتد — معمولاً نه بیدرنگ بلکه در عملیاتی کمپیشآمد مانند بارگذاری فایل یا فرستادن ایمیل.
ترتیب درست:
sudo aa-complain /etc/apparmor.d/usr.sbin.nginxیک هفته کار در این حالت با پوشش هر سناریوی نامعمول: گرفتن نسخه پشتیبان، یک بهروزرسانی، بارگذاری فایلهای بزرگ. سپس آنچه انباشته شده را مرور کنید:
sudo aa-logprofاین فرمان تخلفهای ثبتشده را یکبهیک میگذراند و درباره هر یک میپرسد آیا مجاز شود. اینجا دقت لازم است: آنچه را واقعاً به کار سرویس تعلق دارد مجاز کنید، نه هر چه پیش چشمتان میآید — وگرنه پروفایلی به دست میآید که همهچیز را مجاز میکند و معنا از میان میرود.
و تنها پس از آن:
sudo aa-enforce /etc/apparmor.d/usr.sbin.nginxردها را کجا ببینیم
همه تخلفها به ژورنال هسته میرسند:
sudo journalctl -k | grep -i apparmor
sudo grep 'apparmor="DENIED"' /var/log/audit/audit.logفایل دوم اگر auditd نصب باشد وجود دارد — و با آن ثبتها آشکارا مفصلترند. ثبت یک رد نام پروفایل و عملیات درخواستشده و مسیری را که به آن دسترسی خواسته شده نشان میدهد؛ و این بس است تا بدانید باید پروفایل را اصلاح کنید یا از فعالشدنش شاد باشید.
و یک نشانه ارزش بهخاطرسپردن دارد: سرویس عجیب رفتار میکند — پیکربندی را نمیخواند، در پوشهای نمینویسد، سوکتی باز نمیکند — در حالی که گزارشهای خودش خطای «permission denied» را با مجوزهایی آشکارا درست نشان میدهند. این تقریباً همیشه AppArmor است، و نخستین کار نگاهکردن در ژورنال هسته است.
اقدامی عملی، نه نظری
پروفایلی برای PHP-FPM یا nginx بهشکلی مشخص خودش را جبران میکند. با فرایندی محدودشده، وبشلی که به سایت رسیده نه میتواند فایلهای سامانه را بخواند، نه پوستهای اجرا کند، و نه چیزی بیرون از پوشههای مجاز بنویسد. سایت هکشده سایت هکشده میماند بهجای آنکه به دسترسی به تمام ماشین بدل شود — و همین گذار است که بیشترین زیان را میسازد.
ترتیب معقول بهکارگیری: نخست پروفایلی برای آنچه به اینترنت مینگرد (وبسرور، PHP-FPM)، سپس برای پایگاههای داده، و سپس بر پایه نیاز. لازم نیست همه را یکجا فعال کنید، و مجموعه آماده جهانشمولی وجود ندارد: پروفایل به آنجا بستگی دارد که فایلهای شما کجایند.
چه چیزی را منظم بررسی کنیم
پروفایلها بیش از آنکه گمان کنید به unconfined بازمیگردند: بهروزرسانی بسته ممکن است فایل پروفایلی را جایگزین کند، عیبیابی دستی سرویسی را در complain رها میکند، و سرویس تازه بیهیچ پروفایلی میآید. دو عدد سودمندند: چند پروفایل در enforce است، و چند فرایند رو به شبکه در unconfined. و آگاهی از تغییر هر یک ارزش دارد. شکل گردآمده این در یک صفحه را نمایش پایین نشان میدهد.