معرفی
این راهنما بر پایه مستندات رسمی پروژه نوشته شده و هدف آن ساختن یک مدل ذهنی دقیق برای طراحی، عملیات و عیب‌یابی است.
نکته 1
AppArmor policy را به برنامه‌ها و مسیرهای فایل گره می‌زند و می‌تواند دسترسی فایل، capability، network و execution را محدود کند.
نکته 2
Complain mode برای مشاهده policy hit مفید است اما enforcement واقعی نیست.
نکته 3
Profile باید با رفتار legitimate برنامه تست شود تا false positive به خاموش‌کردن کل کنترل منجر نشود.
برداشت عملیاتی IROSG
قبل از هر تغییر Production، نسخه، وابستگی، سطح دسترسی، rollback و observability را بررسی کنید. منبع رسمی همین صفحه مرجع اصلی جزئیات است.
دو لایه مجوز را جدا بررسی کنید
AppArmor کنترل دسترسی معمول Unix را تکمیل می‌کند. اگر کاربر سرویس طبق مالکیت و mode حق خواندن فایل را ندارد، افزودن اجازه در profile آن مجوز معمول را ایجاد نمی‌کند. برعکس، خواندن مجاز در Unix ممکن است در profile محدود شده باشد. هنگام خطای دسترسی، ابتدا هویت واقعی فرایند و مسیر فایل را ثبت کنید، سپس هر دو لایه را بخوانید. تغییر هم‌زمان مالکیت فایل و profile فهم علت را دشوار می‌کند و ممکن است دسترسی بیش از نیاز بسازد.
برای نمونه یک برنامه گزارش‌گیری را در نظر بگیرید که باید داده ورودی را بخواند و نتیجه را در پوشه خروجی بنویسد. پوشه ورودی و خروجی را جدا کنید و برای فایل تنظیمات فقط خواندن را در نظر بگیرید. اگر همه مسیر پروژه مجوز نوشتن بگیرد، برنامه آسیب‌دیده می‌تواند تنظیم یا کد خود را تغییر دهد. هدف profile توصیف نیاز واقعی برنامه است، نه بازسازی اختیار کامل کاربری که آن را اجرا می‌کند. این تفاوت پایه کاهش دامنه آسیب است.
profile مؤثر را پیدا کنید
وجود یک فایل در پوشه تنظیمات به معنی فعال بودن آن در کرنل نیست. وضعیت بارگذاری و حالت profile را با ابزار وضعیت بررسی کنید و مطمئن شوید فرایند مورد نظر واقعاً زیر همان profile اجرا می‌شود. مسیر باینری، روش اجرای سرویس و سازوکار بسته‌بندی می‌توانند روی انتخاب profile اثر بگذارند. اگر برنامه از مسیر متفاوت یا wrapper اجرا شده است، فرض اینکه نام آشنا همان سیاست قبلی را فعال می‌کند کافی نیست.
پس از ویرایش، بارگذاری دوباره را به صورت هدفمند انجام دهید و نتیجه را بخوانید. خطای نحوی می‌تواند باعث شود تغییر مورد انتظار اعمال نشود و نسخه قبلی همچنان رفتار را تعیین کند. در پرونده تغییر، هم فایل پیشنهادی و هم شاهد وضعیت مؤثر را نگه دارید. این کار از وضعیتی جلوگیری می‌کند که مدیر تصور می‌کند اجازه تازه فعال است ولی برنامه هنوز با سیاست قبلی رد می‌شود. آزمون واقعی باید بعد از تأیید بارگذاری اجرا شود.
حالت یادگیری را با پذیرش نهایی اشتباه نگیرید
حالت complain برای دیدن رفتار و ساختن profile مفید است، اما موفق شدن برنامه در این حالت اثبات کافی بودن سیاست enforce نیست. همچنین قواعد صریح و رفتار گزارش‌دهی جزئیات خود را دارند؛ سکوت log را به معنی مجاز بودن همه چیز نگیرید. در روند توسعه، ابتدا مجموعه عملیات مجاز را تعریف کنید، سپس داده مشاهده را جمع کنید و قوانین پیشنهادی را بررسی کنید. مرحله نهایی باید با حالت اجرایی و آزمون منفی انجام شود.
یک برنامه فقط هنگام شروع به فایل‌ها دسترسی ندارد. reload، چرخش log، تعویض گواهی، تولید فایل موقت و خاموش شدن نیز مسیرهای جدا دارند. اگر دوره یادگیری تنها صفحه اول برنامه را ببیند، profile در عملیات روز بعد ممکن است ناقص باشد. برای هر حالت یک نمونه بی‌خطر طراحی کنید. مثلاً تعویض گواهی آزمایشی را انجام دهید و ببینید برنامه می‌تواند فایل تازه را بخواند بدون آنکه اجازه خواندن همه کلیدهای میزبان را بگیرد.
خواندن پیام رد دسترسی
در log، نام profile، عملیات، مسیر یا مقصد و مجوز درخواست‌شده را کنار هم بخوانید. عبارت DENIED به تنهایی نمی‌گوید باید چه قانونی اضافه شود. ممکن است برنامه به مسیر اشتباه اشاره کرده باشد یا فایل حساس را بی‌دلیل درخواست کند. زمان رخداد را با درخواست کاربردی تطبیق دهید تا پیام یک فرایند دیگر وارد تحلیل نشود. اگر چند نمونه برنامه دارید، شناسه فرایند و واحد سرویس برای تشخیص نمونه درست اهمیت دارد.
پیش از افزودن قانون، از خود بپرسید آیا این دسترسی بخشی از قرارداد برنامه است. برای مثال برنامه‌ای که قرار است فایل مشخصی را بخواند ولی به ریشه پوشه شخصی کاربر سر می‌زند، شاید تنظیم اشتباه دارد. اصلاح تنظیم می‌تواند بهتر از باز کردن مسیر باشد. ابزار پیشنهاددهنده بر اساس مشاهده می‌داند چه چیزی درخواست شده، اما از نیت طراحی شما خبر ندارد. بازبینی انسانی همین فاصله میان رفتار دیده‌شده و رفتار مطلوب را پر می‌کند.
قواعد مسیر و خطر الگوهای گسترده
الگوهای مسیر نگه‌داری profile را آسان می‌کنند، ولی گستردگی آن‌ها باید آگاهانه باشد. اجازه یک فایل با اجازه همه زیرپوشه‌ها نتیجه امنیتی متفاوتی دارد. برای پوشه‌ای که فایل‌های تصادفی یا موقت می‌سازد، محدوده نام و عملیات لازم را جدا تعیین کنید. مجوز خواندن، نوشتن و اجرا را یک بسته واحد فرض نکنید. فایل خروجی داده معمولاً نباید فقط به خاطر نیاز نوشتن، قابلیت اجرای برنامه تازه را هم ایجاد کند.
مسیرهایی که توسط symlink، mount یا محیط کانتینری دیده می‌شوند نیاز به بررسی دقیق‌تر دارند. آنچه برنامه در namespace خود می‌بیند ممکن است با تصور مدیر از مسیر میزبان تفاوت داشته باشد. با یک نمونه آزمایشی، مسیر واقعی استفاده‌شده و log مربوط را بررسی کنید. حدس زدن بر اساس نام پوشه در shell مدیر می‌تواند قانون نادرست بسازد. مستندات همان نسخه و روش اجرای برنامه برای تفسیر این موارد مرجع اصلی‌اند.
اجرای برنامه فرزند
یک سرویس ممکن است برای کار خود ابزار دیگری اجرا کند. تصمیم درباره اینکه فرزند همان محدودیت را به ارث ببرد یا به profile دیگری منتقل شود، بخش مهم طراحی است. اجازه اجرای فایل را بدون فهم حالت انتقال انتخاب نکنید. برای نمونه برنامه گزارش‌گیری که مبدل تصویر اجرا می‌کند، نباید از این مسیر اختیار گسترده‌ای به فرایند فرزند بدهد. رفتار ابزار فرزند و فایل‌های مورد نیاز آن باید در آزمون پوشش داده شوند.
برای تمرین، یک ابزار فرزند بی‌خطر و قابل پیش‌بینی انتخاب کنید و هم اجرای مورد انتظار و هم اجرای فایل خارج از فهرست را بررسی کنید. نتیجه باید نشان دهد فرزند با چه profileای کار می‌کند. اگر فقط خروجی نهایی را ببینید، ممکن است فرایند فرزند از محدودیت خارج شده باشد و آزمون ظاهراً موفق شود. مشاهده هویت و confinement فرایند در کنار نتیجه کاربردی، کیفیت آزمون را بالا می‌برد.
capability و شبکه
برخی نیازها به فایل محدود نیستند. برنامه ممکن است درخواست capability خاص یا عملیات شبکه داشته باشد. این موارد را از مجوز مسیر جدا بررسی کنید و برای رفع یک خطای ساده، مجموعه بزرگی از capabilityها را اضافه نکنید. اگر برنامه باید فقط از یک سرویس بیرونی استفاده کند، توجه داشته باشید دامنه محدودسازی قابل بیان به قابلیت نسخه و نوع قاعده وابسته است. profile جای تمام سیاست‌های فایروال و کنترل مجوز در برنامه را نمی‌گیرد.
در آزمایش شبکه، اتصال مجاز، مقصد نامعتبر و قطع وابستگی را جدا بررسی کنید. خطای resolve نام با رد شدن اتصال در profile یکی نیست. log برنامه، گزارش AppArmor و نتیجه آزمایش شبکه باید روی یک خط زمانی قرار گیرند. این روش مشخص می‌کند آیا لازم است profile تغییر کند یا تنظیم resolver و مقصد برنامه. افزودن اجازه وسیع شبکه برای رفع نام اشتباه، علت را پنهان می‌کند و سطح دسترسی را بالا می‌برد.
نگه‌داری تغییر محلی در برابر بسته توزیع
بعضی بسته‌ها profile آماده دارند و ساختارهایی برای تغییر محلی فراهم می‌کنند. پیش از ویرایش مستقیم فایل اصلی، روش پیشنهادی همان بسته را بخوانید تا ارتقای بعدی تغییر شما را گم نکند یا اختلاف پیچیده نسازد. یک include محلی مناسب می‌تواند نیاز اختصاصی را از سیاست عمومی بسته جدا نگه دارد. با این حال فایل محلی هم باید بازبینی شود؛ قدیمی ماندن استثناها می‌تواند امنیت نسخه جدید را تضعیف کند.
پس از ارتقای برنامه، مجموعه آزمون را دوباره اجرا کنید. مسیرهای داده، نام ابزارهای فرزند یا روش نوشتن فایل ممکن است تغییر کرده باشند. هر denial تازه نشانه نقص profile نیست؛ ممکن است رفتار جدید برنامه نیازمند تصمیم طراحی باشد. تغییر را به نسخه و نیاز مشخص وصل کنید. اگر برنامه دیگر به مسیر قدیمی نیاز ندارد، اجازه آن را نیز حذف کنید تا profile صرفاً با گذر زمان بزرگ‌تر نشود.
برنامه پذیرش و بازگشت محدود
برای پذیرش، سه نوع آزمون داشته باشید: عملیات عادی، عملیات نگه‌داری و دسترسی عمداً خارج از دامنه. نتیجه باید موفقیت دو گروه اول و رد گروه سوم را نشان دهد. سپس restart سرویس و راه‌اندازی دوباره محیط آزمایشی را بررسی کنید تا بارگذاری پایدار profile روشن شود. فایل صحیحی که فقط یک‌بار دستی بارگذاری شده، هنوز تنظیم پایدار قابل اتکا نیست.
اگر تغییر باعث اختلال شد، بازگشت به profile قبلی را به خاموش کردن کل سازوکار ترجیح دهید. نسخه قبلی و دستور بارگذاری آن باید از قبل موجود باشد. پس از برگشت، وضعیت مؤثر و عملیات کاربردی را دوباره تأیید کنید. گزارش تغییر باید دقیقاً بگوید چه دسترسی اضافه یا حذف شد، چه نمونه‌ای آن را لازم کرد و کدام آزمون نشان داد دامنه محدود مانده است. این روش AppArmor را از مانعی مبهم به قراردادی قابل نگه‌داری میان برنامه و سیستم تبدیل می‌کند.
فایل تازه و نوشتن اتمی
بسیاری از برنامه‌ها فایل تنظیم یا خروجی را مستقیم بازنویسی نمی‌کنند؛ ابتدا فایل موقت می‌سازند و سپس آن را جایگزین می‌کنند. profileای که فقط نوشتن نام نهایی را در نظر گرفته باشد ممکن است این الگوی سالم را رد کند. در آزمایش ذخیره‌سازی، نام فایل موقت، پوشه والد و عملیات جایگزینی را از log دنبال کنید. اجازه لازم را به همان الگوی محدود بدهید، نه به همه مسیرهای موقت سیستم.
همچنین چرخش log ممکن است با تغییر مالک یا ایجاد فایل تازه همراه باشد. پس از چرخش آزمایشی، بررسی کنید برنامه همچنان در فایل مورد انتظار می‌نویسد و فایل قبلی بی‌دلیل باز نمانده است. این نمونه نشان می‌دهد profile باید چرخه زندگی داده را پوشش دهد، نه فقط وضعیت ثابت آغاز اجرا. ثبت چنین آزمون‌هایی باعث می‌شود خطاهای دوره‌ای به خاموش کردن سراسری کنترل امنیتی منجر نشوند.
