اگر برای اجرای کدهای ناشناس در سرورهایتان از کانتینرهای سنگین استفاده می‌کنید، احتمالاً نیمی از منابع سیستم شما صرف مدیریت لایه‌های اضافی شده است. Z-Jail این معادله را تغییر می‌دهد و امنیت سطح بالا را در حجمی کمتر از ۱۳۰ کیلوبایت جای می‌دهد.
طبق مستندات منتشرشده توسط Division-36، این ابزار اجازه می‌دهد کدهای بومی (Native) غیرقابل‌اعتماد را از طریق هفت لایه‌ی دفاعی مستقل اجرا کنید. Z-Jail به صورت یک فایل باینری PIE عرضه شده که برای حذف وابستگی‌های خارجی، تنها بر زنجیره ابزارهای استاندارد C تکیه دارد و هیچ وابستگی خارجی ندارد.
بسیاری از ابزارهای ایزوله‌سازی، توسعه‌دهنده را بین امنیت و سربار سیستم مجبور به انتخاب می‌کنند. راهکارهای سنگین‌وزنی مانند Firecracker ایزولاسیون در سطح ماشین مجازی (VM) ارائه می‌دهند اما به منابع قابل‌توجهی نیاز دارند (حجم باینری بیش از ۲۰ مگابایت). در مقابل، ابزارهای مینیمالی مثل bwrap اغلب فاقد فیلترینگ پیش‌فرض برای فراخوان‌های سیستمی (syscall filtering) هستند. gVisor یک سندباکس ارائه می‌دهد اما برای اجرا به ران‌تایم Go و باینری با حجم بیش از ۴۰ مگابایت نیاز دارد. nsjail نیز با وجود قابلیت‌های زیاد، وابستگی‌های سنگینی دارد و حجم باینری آن حدود ۱ مگابایت است.
Z-Jail به عنوان یک راهکار میانی معرفی شده است. این ابزار به‌طور خاص برای محیط‌هایی مانند خطوط لوله‌ی CI (Continuous Integration)، چالش‌های امنیتی Jail در مسابقات CTF و ارزیابی‌های سبک کد طراحی شده است؛ جایی که نیاز به «دفاع در عمق» (Defense-in-Depth) وجود دارد اما نمی‌خواهند هزینه‌ی سنگین یک ران‌تایم کامل کانتینری را بپردازند.
مقایسه با استانداردهای صنعت
برای درک جایگاه Z-Jail، مقایسه‌ی آن با ابزارهای رایج صنعت ضروری است:
- Z-Jail: صفر وابستگی خارجی، حجم ~۱۳۰ کیلوبایت، لیست سفید seccomp، حسابرسی JSON و هش محتوا.
- Firecracker: ایزولاسیون MicroVM، حجم ۲۰+ مگابایت، بدون لیست سفید seccomp، بدون هش محتوا.
- gVisor: ایزولاسیون سندباکس، حجم ۴۰+ مگابایت، بدون لیست سفید seccomp، دارای حسابرسی JSON.
- bwrap: ساخت بسیار ساده، حجم ~۷۰ کیلوبایت، بدون seccomp پیش‌فرض، بدون هش محتوا.
- nsjail: پیچیدگی ساخت متوسط، حجم ~۱ مگابایت، seccomp اختیاری، حسابرسی جزئی.
هفت لایه‌ی دفاعی
به نقل از مستندات گیت‌هاب، Z-Jail محیط اجرا را از طریق توالی دقیقی از عملیات‌ها ایمن می‌کند. ترتیب این لایه‌ها به‌گونه‌ای است که مراحل بعدی نمی‌توانند توسط مراحل قبلی خنثی یا بازگردانی شوند:
- محدودیت منابع: پروسه با تنظیم
setrlimitشروع می‌شود تا محدودیت‌های CPU، فضای آدرس، تعداد فایل‌های باز و محدودیت‌های پروسه را پیش از هر اقدام دیگری تعیین کند. این کار از حملات بمب فورک (Fork Bomb) و اتمام حافظه (Memory Exhaustion) جلوگیری می‌کند. - پاک‌سازی توصیف‌گرهای فایل: تمام File Descriptorهای ارث‌بری شده (به جز لوله‌ی گزارش یا fds >= 3) بسته می‌شوند تا از نشت داده‌ها در مرز
execveجلوگیری شود. - قفل حافظه: پرچم
PR_SET_DUMPABLE=0فعال می‌شود تا ایجاد Core Dumpها غیرفعال شده و دسترسی به/proc/self/memقفل شود. - ایزولاسیون سیستم‌فایل: این ابزار از
pivot_rootبرای جدا شدن کامل از سیستم‌فایل میزبان استفاده می‌کند. پروسه ابتدا دایرکتوری ریشه را روی خودش Bind-mount می‌کند (MS_BIND|MS_REC)، سپس درخت مونت را از طریقpivot_root(new_root, put_old)جابجا می‌کند، با دستورchdir("/")به ریشه جدید می‌رود و در نهایت ریشه قدیمی را به صورت Lazy با دستورumount2("/.pivot_old", MNT_DETACH)جدا می‌کند. این روش اکیداً قدرتمندتر از chroot استاندارد است، زیرا هیچ راهی برای فرار پروسه سندباکس شده به ریشه میزبان وجود ندارد، حتی اگر از داخل سندباکس ازCLONE_NEWNSاستفاده شود (که البته توسط seccomp مسدود شده است). - محدودیت امتیازات: پرچم
PR_SET_NO_NEW_PRIVSتضمین می‌کند که نه پروسه فعلی و نه فرزندانش نتوانند از طریق باینری‌های setuid، قابلیت‌های فایل (File Capabilities) یا انتقال‌های LSM امتیازات جدید کسب کنند. این عملیات غیرقابل بازگشت است. - حذف قابلیت‌ها (Capabilities): تمام قابلیت‌های لینوکس از طریق
capset(hdr, data)(که در آن داده‌ها {0, 0, 0} هستند) صفر می‌شوند. پروسه پیش ازcapsetشناسه‌های setuid/setgid را رها می‌کند تا تغییر UID در حالی کهCAP_SETUIDهنوز فعال است، اعمال شود. در نهایت، securebits از طریقprctl(شاملSECBIT_KEEP_CAPS_LOCKEDوSECBIT_NO_SETUID_FIXUP) قفل می‌شوند تا هرگونه فعال‌سازی مجدد غیرممکن شود. - فیلترینگ فراخوان‌های سیستمی: یک لیست سفید seccomp-BPF پروسه را تنها به ۱۵ فراخوان مجاز محدود می‌کند. هرگونه تلاش برای فراخوانی توابع ممنوعه، منجر به مرگ فوری پروسه از طریق
SECCOMP_RET_KILLمی‌شود.
پیاده‌سازی فضای نام (Namespace)
Z-Jail برای تضمین ایزولاسیون کامل، از پنج فضای نام (Namespace) خاص استفاده می‌کند که از طریق clone() ایجاد می‌شوند. این عملیات نیازمند دسترسی CAP_SYS_ADMIN در فضای نام اولیه است:
- Mount (
CLONE_NEWNS): فراهم کردن یک درخت سیستم‌فایل ایزوله. - PID (
CLONE_NEWPID): ایجاد فضای شناسه‌ی پروسه مجزا که در آن فرزند به PID 1 تبدیل می‌شود. - Net (
CLONE_NEWNET): تضمین اینکه هیچ رابط شبکه‌ای در دسترس نباشد. - IPC (
CLONE_NEWIPC): جلوگیری از دسترسی به حافظه مشترک یا سمافورها. - UTS (
CLONE_NEWUTS): فراهم کردن یک نام میزبان (Hostname) مجزا.
جزئیات لیست سفید seccomp
فیلتر seccomp-BPF به‌صورت پویا تولید می‌شود و برای هر ورودی یک زنجیره پرش (jump chain) ایجاد می‌کند. این فیلتر ابتدا تایید می‌کند که معماری سیستم AUDIT_ARCH_X86_64 باشد. ۱۵ فراخوان مجاز عبارت‌اند از:
- ورودی/خروجی پایه:
read(0),write(1),close(3),lseek(8). - حافظه:
brk(12),munmap(11) وmmap(9). فراخوانmmapبه شدت محدود شده است: پرچم‌ها باید دقیقاً0x22(MAP_PRIVATE|MAP_ANONYMOUS) باشند و استفاده ازMAP_SHARED(flags & 4) اکیداً ممنوع است. - کنترل پروسه:
execve(59) برای شروع اولیه وexit_group(231) برای خروج تمیز. - سیستمی/زمان‌بندی:
rt_sigaction(13),rt_sigprocmask(14),getrandom(318),clock_gettime(228) وfstat(5).
این فیلتر به‌طور مستقل توسط یک تست مجزا (tests/seccomp_filter_test.c) تایید شده است که ۸ مورد از ۸ سناریوی تست را با استفاده از prctl(PR_SET_SECCOMP) و بدون نیاز به دسترسی root با موفقیت پاس می‌کند.
موتور حکم و حسابرسی
علاوه بر ایزولاسیون، Z-Jail شامل موتور حکم Truthimatics Public Version است که یک موتور مبتنی بر شواهد است. این سیستم مشاهدات وزنی را درباره باینری اجرا شده جمع‌آوری می‌کند تا تعیین کند نتیجه DETERMINISTIC (قطعی)، REJECT (رد شده) یا UNCERTAIN (نامشخص) است. اگر هر یک از مشاهدات وزنی بیش از ۵۰٪ از کل وزن را داشته باشد، حکم نهایی بر اساس آن صادر می‌شود.
هر اجرا یک رکورد حسابرسی JSON مفصل تولید می‌کند که در مسیر build/audits/<binary-name>.audit.json ذخیره می‌شود. این رکورد شامل موارد زیر است:
- متادیتا: نسخه طرحواره (
z-jail.audit/v1)، شناسه ساخت (Z-Jail/v1+dev) و برچسب زمانی. - داده‌های اجرا: مدت زمان اجرا به نانوثانیه، کد خروج و مسیر فایل اجرایی.
- وضعیت سندباکس: تایید فعال بودن
no_new_privsوcapabilities_dropped، مسیرpivot_rootو لیست پنج فضای نام استفاده شده (mount,pid,net,ipc,uts). - یکپارچگی: اثر انگشت محتوایی BLAKE2b-256 از باینری هدف که توسط پروسه والد پس از پایان کار فرزند محاسبه می‌شود.
مشخصات فنی و عملکرد
بر اساس تست‌های انجام شده روی WSL2 (کالی لینوکس، GCC 15.2.0، با بهینه‌سازی -O2 -g)، Z-Jail کارایی فوق‌العاده‌ای دارد. تأخیر میانگین سندباکس حدود ۸ میلی‌ثانیه و حداکثر مصرف حافظه (RSS) حدود ۴ مگابایت است. منطق اصلی این ابزار تنها در حدود ۹۰۰ خط کد گنجانده شده است.
تفکیک تقریبی تأخیر:
cloneو فضای نام‌ها: ~۳ میلی‌ثانیهpivot_root: ~۲ میلی‌ثانیه- seccomp و قابلیت‌ها: ~۱ میلی‌ثانیه
execve: ~۱ میلی‌ثانیهwaitpidو حسابرسی: ~۱ میلی‌ثانیه
این ابزار به صورت یک Position Independent Executable (PIE) و با استفاده از -fstack-protector-strong ، -D_FORTIFY_SOURCE=2 ، RELRO کامل و -z now ساخته شده است. برای پشتیبانی از فضای نام‌ها و ویژگی‌های seccomp-BPF، به هسته لینوکس نسخه ۵.۴ یا بالاتر نیاز دارد و با نسخه‌های GCC 11.4، 13.2 و 15.2 سازگار است.
مدل تهدید و محدوده حفاظتی
Z-Jail برای متوقف کردن کدهای بومی طراحی شده که سعی دارند از طریق chroot، mount، ptrace یا فراخوان‌های socket از محیط فرار کنند. همچنین با استفاده از RLIMIT_NPROC جلوی بمب‌های فورک و با RLIMIT_AS جلوی اتمام حافظه را می‌گیرد.
حفاظت‌های فعال (In-Scope):
- فرار از طریق
ptrace،socketیاprocess_vm_writev. - نشت توصیف‌گرهای فایل در مرز
execve. - ارتقای امتیازات از طریق
setuid، لینکرهای دینامیک یاLD_PRELOAD. - حذف فیلتر seccomp یا فعال‌سازی مجدد قابلیت‌ها.
خارج از محدوده (Out-of-Scope):
- آسیب‌پذیری‌های Zero-day در هسته لینوکس که خارج از سطح ۱۵ فراخوان مجاز باشند.
- کانال‌های جانبی سخت‌افزاری (مانند Spectre و Meltdown).
- فرار از VMهای هم‌جوار از طریق مونت‌های مشترک
/procیا/sys. - ایجاد کمبود منابع برای سندباکس‌های هم‌سایه (که نیازمند پشتیبانی cgroup است).
نحوه استفاده و پیاده‌سازی
Z-Jail از طریق یک CLI مدیریت می‌شود که به یک دایرکتوری --root حاوی یک سیستم‌فایل مینیمال نیاز دارد. برای باینری‌های استاتیک، تنها حضور خود باینری در این دایرکتوری کافی است. پرچم‌های کلیدی شامل --seccomp-enforce برای فعال‌سازی لیست سفید و --self-hash=<hex> برای تایید هش BLAKE2b-256 باینری پیش از اجرا است.
کدهای خروج داده‌های دقیقی ارائه می‌دهند:
- ۰: خروج عادی (DETERMINISTIC).
- ۱: کشته شدن توسط سیگنال (REJECT).
- ۲/۳: خطاهای مربوط به self-hash (فرمت اشتباه یا عدم تطابق).
- ۱۰۱-۱۰۵: شکست در مراحل راه‌اندازی (به ترتیب: rlimit, seccomp, execve, pivot_root, یا capabilities).
- ۱۲۵: شکست در ایجاد فضای نام (Namespace).
تحلیل: تغییر خط پایه سندباکس‌ها
برای جامعه برنامه‌نویسی سیستم‌ها، Z-Jail این فرض را تغییر می‌دهد که ایزولاسیون با امنیت بالا لزوماً نیازمند یک ران‌تایم سنگین است. با ترکیب pivot_root و یک لیست سفید سخت‌گیرانه ۱۵ فراخوانی، این ابزار ثابت می‌کند که یک باینری زیر ۲۰۰ کیلوبایت می‌تواند دفاع در عمق معناداری ارائه دهد.
این رویکرد برای توسعه‌دهندگانی که سیستم‌های تصحیح خودکار کد می‌سازند یا پژوهشگران امنیتی که نیاز به اجرای Payloadهای ناشناس دارند، بسیار مفید است. Z-Jail مسیر را از ایزولاسیون «همه یا هیچ» (ماشین مجازی در مقابل پروسه) به سمت یک رویکرد لایه‌بندی شده و دانه‌بندی شده می‌برد که به اندازه کافی سریع است تا در تریگرهای با فرکانس بالای CI استفاده شود.
گام‌های بعدی
کاربران می‌توانند با کلون کردن مخزن و اجرای مجموعه تست ۱۷ سناریویی، پیاده‌سازی را بررسی کنند. این مجموعه همه چیز را پوشش می‌دهد؛ از blake2b_regress و منطق seccomp_filter گرفته تا مسدود کردن mmap با PROT_EXEC یا MAP_SHARED و جلوگیری از فرارهای chroot. سناریوهای خاص عبارت‌اند از:
- سناریو ۶ و ۸: مسدود کردن
MAP_SHAREDوPROT_EXECدرmmap. - سناریو ۱۰ تا ۱۴: مسدود کردن فراخوان‌های
ptrace،socket،chrootوmount. - سناریو ۱۵: تست
RLIMIT_NPROCدر برابر بمب‌های فورک.
در نقشه راه نسخه ۲ (v2)، موارد زیر برنامه‌ریزی شده است:
- فایل‌های پالیسی seccomp خارجی (در قالب JSON یا سورس BPF).
- پرچم‌های فضای نام سفارشی برای هر نمونه سندباکس.
- لیست‌های سفید فراخوان‌های سیستمی قابل تنظیم از طریق CLI.
- قلاب‌های پروفایلینگ عملکرد برای ادغام در CI.
- امضای نسخه‌ها با استفاده از minisign یا signify.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو