معرفی
این راهنما بر پایه مستندات رسمی پروژه نوشته شده و هدف آن ساختن یک مدل ذهنی دقیق برای طراحی، عملیات و عیب‌یابی است.
نکته 1
seccomp filter روی شماره syscall و argumentها policy می‌سازد و actionهایی مثل allow، errno، trap یا kill دارد.
نکته 2
allowlist سخت‌گیرانه بدون تست می‌تواند compatibility را بشکند.
نکته 3
seccomp privilege را حذف نمی‌کند؛ باید با namespace، capability و LSM ترکیب شود.
برداشت عملیاتی IROSG
قبل از هر تغییر Production، نسخه، وابستگی، سطح دسترسی، rollback و observability را بررسی کنید. منبع رسمی همین صفحه مرجع اصلی جزئیات است.
فراخوانی سامانه مرز ورود به هسته است
برنامه کاربر برای بسیاری از عملیات مانند باز کردن فایل، ساخت فرایند یا ارتباط شبکه از هسته درخواست می‌کند. این درخواست‌ها از طریق فراخوانی‌های سامانه انجام می‌شوند. seccomp امکان محدود کردن این سطح درخواست را فراهم می‌کند. ایده اصلی این است که برنامه‌ای با وظیفه محدود، نباید بدون نیاز به همه مسیرهای هسته دسترسی داشته باشد. با این حال، محدود کردن فراخوانی به تنهایی محیط کامل جداسازی نمی‌سازد. دسترسی فایل، هویت کاربر، فضای نام و شبکه همچنان به کنترل‌های دیگر نیاز دارند.
برای مثال، یک مبدل تصویر ممکن است پس از شروع فقط داده ورودی را بخواند، پردازش کند و خروجی بنویسد. کاهش فراخوانی‌های غیرضروری می‌تواند سطح حمله را کم کند، اما اگر برنامه به فایل حساس از قبل دسترسی دارد، مجاز بودن خواندن همچنان آن دسترسی را باقی می‌گذارد. بنابراین باید بپرسید چه عملیاتی حذف می‌شود و چه عملیاتی هنوز مجاز است. نام «فیلتر امنیتی» نباید باعث شود همه مسیرهای سوءاستفاده بسته فرض شوند.
فیلتر چه داده‌ای را می‌بیند؟
فیلتر می‌تواند بر اساس اطلاعات فراخوانی، از جمله شماره و بعضی مقدارهای آرگومان، تصمیم بگیرد. این با فهم معنای کامل داده‌ای که یک اشاره‌گر به آن اشاره می‌کند یکسان نیست. برای نمونه، بررسی مقدار یک آرگومان عددی با اعمال سیاست پیچیده بر محتوای رشته مسیر تفاوت دارد. از seccomp انتظار یک سیاست‌گذار کامل نام فایل نداشته باشید. اگر نیاز اصلی محدود کردن دسترسی به مسیرهاست، باید سازوکار مناسب کنترل فایل و محیط فرایند نیز طراحی شود.
این مرز برای جلوگیری از سیاست‌های ظاهراً دقیق مهم است. ممکن است نویسنده تصور کند مجاز کردن یک فراخوانی فقط برای یک کاربرد خاص کافی است، در حالی که همان فراخوانی راه‌های دیگری هم دارد. پیش از نوشتن فیلتر، معنای آرگومان‌ها، معماری و رفتار کتابخانه مورد استفاده را بررسی کنید. یک قاعده کوتاه بدون شناخت رابط هسته می‌تواند یا برنامه را بی‌دلیل متوقف کند یا اختیار بیش از انتظار باقی بگذارد.
معماری پردازنده بخشی از تصمیم است
شماره و قرارداد فراخوانی‌ها به معماری و رابط اجرایی وابسته‌اند. فیلتر نباید فقط چند شماره خام را بدون بررسی معماری تفسیر کند. پشتیبانی از حالت‌های سازگاری نیز می‌تواند پیچیدگی ایجاد کند. استفاده از کتابخانه و پروفایل معتبر کمک می‌کند، اما جای آزمون روی محیط واقعی را نمی‌گیرد. تصویری که روی یک معماری سالم اجرا می‌شود ممکن است روی معماری دیگر به مجموعه فراخوانی متفاوتی نیاز داشته باشد.
در گزارش آزمایش، معماری، نسخه هسته، کتابخانه پایه و محیط اجرا را ثبت کنید. این اطلاعات برای توضیح خطای پس از جابه‌جایی ضروری‌اند. اگر تیم چند نوع گره دارد، آزمون فقط روی لپ‌تاپ توسعه کافی نیست. یک برنامه ممکن است در شرایط عادی از مسیر کتابخانه‌ای استفاده کند و در وضعیت خاص به مسیر جایگزین برود. سیاست باید رفتارهای واقعاً پشتیبانی‌شده را پوشش دهد، نه فقط یک اجرای خوش‌شانس را.
فهرست مجاز را از مشاهده صرف نسازید
ثبت فراخوانی‌های یک اجرای سالم می‌تواند نقطه شروع باشد، ولی همه نیازهای برنامه را نشان نمی‌دهد. مسیر خطا، راه‌اندازی دوباره، بار زیاد، تغییر اندازه حافظه و ارتباط ناموفق ممکن است فراخوانی‌های دیگری ایجاد کنند. اگر فقط مسیر موفق کوتاه را ثبت و همان را سیاست نهایی کنید، خطا در زمان نامناسب ظاهر می‌شود. پوشش آزمایش باید از رفتار برنامه بیاید، نه از تعداد فراخوانی‌های دیده‌شده در یک نمونه.
برای یک خدمت وب، علاوه بر پاسخ سالم، ورودی نامعتبر، قطع مشتری، خطای نام‌گذاری، پر شدن صف و توقف عادی را آزمایش کنید. برای پردازشگر فایل، فایل خالی، فایل بزرگ، قالب خراب و خطای نوشتن خروجی مهم‌اند. هدف این نیست که همه وضعیت‌های جهان را پیش‌بینی کنید؛ هدف شناخت مسیرهای متفاوتی است که برنامه واقعاً پشتیبانی می‌کند. هر بار افزودن فراخوانی باید با یک نیاز توضیح‌پذیر همراه باشد، نه صرفاً برای ساکت کردن خطا.
واکنش به تخلف بر رفتار برنامه اثر می‌گذارد
سیاست می‌تواند برای فراخوانی نامجاز رفتارهای متفاوتی انتخاب کند، مانند بازگرداندن خطا یا پایان دادن به اجرا؛ قابلیت دقیق به هسته و تنظیم وابسته است. این انتخاب فقط امنیتی نیست، پیامد عملیاتی هم دارد. اگر خطا برگردد، برنامه ممکن است مسیر جایگزین را امتحان کند یا وارد حلقه تکرار شود. اگر اجرا متوقف شود، داده در حال پردازش و درخواست جاری چه می‌شود؟ این پرسش‌ها باید در آزمایش پاسخ داده شوند.
یک تخلف ساختگی را در برنامه آزمایشی ایجاد کنید و گزارش، وضعیت خروج و واکنش ناظر خدمت را ببینید. آیا سرویس فوراً و بی‌پایان راه‌اندازی دوباره می‌شود؟ آیا پیام خطا برای اپراتور قابل فهم است؟ آیا درخواست کاربر پاسخ مشخص می‌گیرد؟ انتخاب واکنش باید با هدف کاهش خطر و قابلیت تشخیص هماهنگ باشد. سیاستی که تخلف را پنهان می‌کند یا طوفان راه‌اندازی مجدد می‌سازد، نگهداری دشوارتری دارد.
زمان اعمال فیلتر اهمیت دارد
برنامه در مرحله شروع ممکن است به کارهایی نیاز داشته باشد که پس از آماده شدن دیگر لازم نیستند. بارگذاری کتابخانه، خواندن تنظیمات و ساخت منابع اولیه از نمونه‌های این تفاوت‌اند. اعمال فیلتر بسیار زود می‌تواند شروع را خراب کند؛ اعمال بسیار دیر، پنجره اختیار گسترده ایجاد می‌کند. طراحی باید با چرخه عمر برنامه هماهنگ باشد. اگر چند نخ وجود دارد، پوشش آن‌ها و نحوه هماهنگ شدن سیاست را طبق رابط و ابزار مورد استفاده بررسی کنید.
در محیط ظرفی، زمان اعمال پروفایل را معمولاً محیط اجرا مدیریت می‌کند و برنامه اختیار کامل روی آن ندارد. بنابراین پروفایل باید نیازهای راه‌اندازی را هم پوشش دهد. اگر برنامه خودش مرحله‌بندی امنیتی دارد، آن را جدا مستند کنید. ترکیب دو لایه فیلتر ممکن است محدودیت نهایی متفاوتی بسازد. هنگام عیب‌یابی، همه لایه‌های اعمال‌کننده را فهرست کنید تا تغییر در یک فایل با انتظار اشتباه درباره سیاست مؤثر همراه نشود.
مجوزهای دیگر همچنان لازم‌اند
اجرای کاربر غیرریشه، حذف قابلیت‌های اضافی و محدود کردن مسیرهای قابل نوشتن مکمل seccomp هستند. هرکدام زاویه متفاوتی از اختیار را محدود می‌کنند. یک فراخوانی مجاز ممکن است به دلیل مجوز فایل شکست بخورد و یک فراخوانی نامجاز ممکن است پیش از بررسی مجوز فایل متوقف شود. برای تشخیص، خطای برنامه، رخدادهای امنیتی و تنظیم مؤثر را کنار هم بخوانید. افزایش دسترسی کاربر برای حل خطای ناشی از فیلتر معمولاً علت را برطرف نمی‌کند و خطر را بیشتر می‌کند.
همچنین شبکه و رازهای برنامه جدا هستند. اگر برنامه مجاز به ارسال داده به مقصدی است، فیلتر فراخوانی به تنهایی سیاست کامل مقصد شبکه نمی‌سازد. رازهایی که در حافظه برنامه قرار دارند نیز با فعال شدن فیلتر خودکار پنهان نمی‌شوند. مدل تهدید را روشن نگه دارید: کاهش سطح تماس با هسته یک هدف مشخص است، نه تضمین مصونیت کامل از نشت یا منطق مخرب در خود برنامه.
پروفایل پیش‌فرض یا سفارشی
پروفایل پیش‌فرض محیط اجرا معمولاً برای سازگاری گسترده طراحی شده است. پروفایل سفارشی می‌تواند محدودتر باشد، اما هزینه نگهداری آن بیشتر است. اگر تیم توان آزمون نسخه‌های جدید برنامه و وابستگی‌ها را ندارد، یک فهرست بسیار محدود ممکن است به استثناهای اضطراری و حذف کامل کنترل منجر شود. سطح محدودیت را با توان عملیاتی هماهنگ کنید. هدف، سیاستی است که در انتشارهای بعدی هم قابل حفظ باشد.
برای ساخت پروفایل سفارشی، از یک برنامه کوچک و کم‌خطر شروع کنید. نیازها را مستند کنید، آزمون‌های رفتاری را اجرا کنید و تخلف کنترل‌شده را ببینید. سپس انتشار را مرحله‌ای انجام دهید و نرخ خطا و توقف فرایند را زیر نظر بگیرید. نسخه پروفایل را به نسخه برنامه پیوند دهید تا بازگشت قابل توضیح باشد. تغییر همزمان برنامه، کتابخانه پایه و فیلتر، یافتن علت خطا را دشوار می‌کند.
قابلیت‌های پیشرفته نیاز به مرز اعتماد روشن دارند
بعضی رابط‌ها امکان تصمیم‌گیری یا میانجی‌گری توسط فرایند دیگری را فراهم می‌کنند. چنین طراحی‌هایی می‌توانند مفید باشند، اما فرایند ناظر خود بخشی از مرز امنیت می‌شود. باید معلوم باشد چه داده‌ای را بررسی می‌کند، چه اختیاری دارد و چگونه از تغییر وضعیت بین بررسی و استفاده جلوگیری می‌شود. استفاده از نام یک قابلیت پیشرفته به تنهایی امنیت ایجاد نمی‌کند. برای بیشتر تیم‌ها، شروع با سیاست ساده و قابل آزمون بهتر از ساخت میانجی پیچیده بدون مدل اعتماد روشن است.
اگر این مسیر لازم است، شکست ناظر، تأخیر پاسخ و مصرف منابع آن را نیز آزمایش کنید. برنامه تحت محدودیت نباید بتواند با درخواست‌های فراوان ناظر را از کار بیندازد یا به مسیر غیرمنتظره سوق دهد. این موارد جزئیات طراحی سامانه‌اند و باید با مستندات رسمی هسته و بازبینی متخصص بررسی شوند. مقاله حاضر هدفش توضیح مرزهاست و جای تحلیل امنیتی یک میانجی اختصاصی را نمی‌گیرد.
معیار پذیرش و نگهداری
یک سیاست آماده باید سه نتیجه را نشان دهد: رفتارهای لازم برنامه سالم‌اند، عملیات ممنوع واقعاً متوقف می‌شوند و علت توقف برای عملیات قابل تشخیص است. پس از ارتقای وابستگی‌ها، این سه آزمون را دوباره اجرا کنید. اگر فراخوانی تازه لازم شد، دلیل را ثبت و اثر آن را بررسی کنید. مستندات رسمی هسته مرجع معنای رفتارهاست، اما تنظیم نهایی باید با هسته واقعی شما تطبیق داشته باشد. ارزش seccomp در کاهش آگاهانه اختیار است؛ فهرست طولانی و نامفهوم فراخوانی‌ها بدون آزمون، معیار کیفیت امنیت نیست.
از خطای مبهم تا علت قابل بازتولید
اگر برنامه پس از فعال شدن پروفایل ناگهان متوقف شد، ورودی و مرحله دقیق توقف را ثبت کنید. همان ورودی را در محیط آزمایشی با سیاست شناخته‌شده مقایسه کنید و گزارش‌های مربوط به تخلف را بخوانید. حذف کامل فیلتر در تولید برای مدت نامعلوم، راه تشخیص پایدار نیست. هدف پیدا کردن کوچک‌ترین رفتار لازم و فراخوانی مرتبط است. پس از اصلاح پروفایل، ورودی مشکل‌دار باید موفق شود و آزمون عملیات ممنوع همچنان شکست بخورد. این دو آزمون کنار هم نشان می‌دهند اصلاح، سازگاری را برگردانده بدون آنکه محدودیت هدف بی‌دلیل کنار گذاشته شود. نتیجه را همراه دلیل تغییر در تاریخچه پروفایل ثبت کنید.
