سوالات متداول

آیا می‌توانم از نخ‌ها استفاده کنم؟

بله، رشته‌ها در Sandbox2 پشتیبانی می‌شوند.

همه رشته‌ها باید سندباکس شوند

به دلیل نحوه‌ی عملکرد لینوکس، سیاست seccomp-bpf فقط روی نخ فعلی اعمال می‌شود: این بدان معناست که این سیاست روی سایر نخ‌های موجود اعمال نمی‌شود، اما نخ‌های آینده این سیاست را به ارث خواهند برد:

• اگر از Sandbox2 در حالت اول استفاده می‌کنید که در آن sandboxing قبل از execve() فعال است، همه نخ‌ها این خط‌مشی را به ارث می‌برند و مشکلی وجود ندارد. این حالت ترجیحی sandboxing است.
• اگر از حالت دوم استفاده می‌کنید که در آن اجراکننده set_enable_sandbox_before_exec(false) را فعال کرده است و Sandboxee با SandboxMeHere() به اجراکننده می‌گوید چه زمانی می‌خواهد در جعبه شنی قرار گیرد، مطمئن شوید که فیلتر روی همه نخ‌ها اعمال شده است. در غیر این صورت، خطر فرار از جعبه شنی وجود دارد: کد مخرب می‌تواند از یک نخ جعبه شنی شده به یک نخ جعبه شنی نشده مهاجرت کند.

Note: The Linux kernel introduced the TSYNC flag in version 3.17, which allows applying a policy to all threads. Before this flag, it was only possible to apply the policy on a thread-by-thread basis. If Sandbox2 detects that it is running on a kernel without TSYNC-support and you call SandboxMeHere() from a multi-threaded program, Sandbox2 will abort, since this would compromise the safety of the sandbox.

چگونه باید Sandboxee خود را کامپایل کنم؟

در مقایسه با یک فایل اجرایی با پیوند ایستا، کامپایل کردن سندباکس به یک فایل اجرایی با پیوند پویا منجر به افزایش قابل توجه فراخوانی‌های سیستمی (مثلاً open / openat ، mmap و غیره) می‌شود که باید در لیست مجاز قرار گیرند. همه این فراخوانی‌های سیستمی اضافی به دلیل فراخوانی پویای پیوند دهنده در زمان اجرا برای بارگذاری کتابخانه‌های مشترک مورد نیاز هستند.

با این حال، با نگاهی به سندباکس‌های با پیوند استاتیک: در حالی که فراخوانی‌های سیستمی کمتری باید در لیست مجاز قرار گیرند، پیامدهای امنیتی نیز وجود دارد؛ آنتروپی هیپ ASLR کاهش می‌یابد (از 30 بیت به 8 بیت)، که سوءاستفاده‌ها را آسان‌تر می‌کند.

این یک معضل است که اساساً می‌توان آن را به موارد زیر تقلیل داد:

• پویا : ASLR خوب برای هیپ، که به طور بالقوه اجرای اولیه کد را دشوارتر می‌کند اما به قیمت سیاست جعبه شنی کم‌اثرتر تمام می‌شود، و به طور بالقوه خروج از آن آسان‌تر است.
• استاتیک : ASLR بد در heap، که به طور بالقوه اجرای اولیه کد را آسان‌تر می‌کند، اما یک سیاست sandbox مؤثرتر است و خروج از آن به طور بالقوه دشوارتر است.

از نظر تاریخی، فایل‌های باینری استاتیک لینک شده از کد مستقل از موقعیت ( pie ) پشتیبانی نمی‌کردند. علاوه بر این، Bazel به طور پیش‌فرض pie را اضافه کرد. برای اینکه بتوانید یک فیلتر فراخوانی سیستمی دقیق تعریف کنید، باید مقدار پیش‌فرض Bazel را بازنویسی می‌کردید.

Compilers have improved over the years and now support a static-pie option. With this option a compiler is instructed to generate position-independent code, but compared to pie this now also includes all the statically linked libraries. From a security standpoint, static-pie still reduces the ASLR entropy (from 30 bits to 14 bits), but this is an improvement over the previous situation without pie .

از آنجایی که Bazel به طور پیش‌فرض pie را اضافه می‌کند و static با آن سازگار نیست، استفاده از پرچم گزینه‌های linker را برای ارسال پرچم linker -static-pie به قانون cc_binary و بازنویسی پیش‌فرض در نظر بگیرید:

  linkstatic = 1,
  linkopts=["-static-pie"],

برای مثالی از این گزینه‌ها، به مثال استاتیک BUILD نگاه کنید: static_bin.cc به صورت استاتیک با static-pie مرتبط شده است، که امکان داشتن یک سیاست فراخوانی سیستمی بسیار دقیق را فراهم می‌کند. این همچنین برای sandboxing فایل‌های باینری شخص ثالث به خوبی کار می‌کند.

آیا می‌توانم فایل‌های باینری ۳۲ بیتی x86 را در محیط سندباکس (sandbox) قرار دهم؟

Sandbox2 فقط می‌تواند همان معماری که با آن کامپایل شده است را در حالت Sandbox اجرا کند.

علاوه بر این، پشتیبانی از معماری x86 32 بیتی از Sandbox2 حذف شده است. اگر سعی کنید از یک اجراکننده معماری x86 64 بیتی برای سندباکس کردن یک فایل باینری x86 32 بیتی یا یک فایل باینری x86 64 بیتی که فراخوانی‌های سیستمی 32 بیتی (از طریق int 0x80) ایجاد می‌کند، استفاده کنید، هر دو یک نقض سندباکس ایجاد می‌کنند که می‌تواند با برچسب معماری [X86-32] شناسایی شود.

The reason behind this behavior is that syscall numbers differ between architectures and since the syscall policy is written in the architecture of the executor, it would be dangerous to allow a different architecture for the Sandboxee. Indeed, this could lead to allowing a seemingly harmless syscall that in fact means another more harmful syscall could open up the sandbox to an escape.

آیا محدودیتی در تعداد sandbox هایی که یک فرآیند اجرایی می‌تواند درخواست کند وجود دارد؟

برای هر نمونه Sandboxee (فرایند جدیدی که از forkserver ایجاد می‌شود)، یک thread جدید ایجاد می‌شود - محدودیت همین جاست.

آیا یک مجری می‌تواند درخواست ایجاد بیش از یک Sandbox را بدهد؟

خیر. یک رابطه ۱:۱ وجود دارد - یک نمونه Executor، PID مربوط به Sandboxee را ذخیره می‌کند، نمونه Comms را به نمونه Sandbox مدیریت می‌کند و غیره.

چرا در forkserver.cc با پیغام "تابع پیاده‌سازی نشده" مواجه می‌شوم؟

Sandbox2 فقط از اجرا روی هسته‌های نسبتاً جدید پشتیبانی می‌کند. محدودیت فعلی ما هسته ۳.۱۹ است، هرچند ممکن است در آینده تغییر کند. دلیل این امر این است که ما از ویژگی‌های هسته نسبتاً جدیدی از جمله فضاهای نام کاربر و seccomp با پرچم TSYNC استفاده می‌کنیم.

اگر از نسخه پرود (prod) استفاده می‌کنید، این موضوع نباید مشکلی ایجاد کند، زیرا تقریباً تمام سیستم عامل‌ها از یک هسته نسبتاً جدید استفاده می‌کنند. اگر در این مورد مشکلی دارید، لطفاً با ما تماس بگیرید.

اگر از دبیان یا اوبونتو استفاده می‌کنید، به‌روزرسانی هسته به آسانی اجرای دستور زیر است:

sudo apt-get install linux-image-<RECENT_VERSION>