طراحی Sandbox2 براساس فناوری‌های شناخته‌شده و تثبیت‌شده، چارچوب خط‌مشی، و دو فرایند ساخته شده است: Sandbox Executor و Sandboxee.
فناوری‌های دخیل
بخش‌های زیر فناوری‌هایی را پوشش می‌دهد که لایه پایه Sandbox2 را می‌سازند.
فضاهای نام Linux
فضاهای نام Linux تلاشی برای ارائه مجازی‌سازی در سطح سیستم‌عامل است. اگرچه چندین فضای کاربر به‌ظاهر مستقل از یکدیگر اجرا می‌شوند، اما از یک نمونه هسته واحد استفاده می‌کنند. Sandbox2 از انواع زیر استفاده می‌کند:
- ارتباط میان پردازشی : IPC
- شبکه (مگر اینکه صریحاً با فراخوانی
PolicyBuilder::AllowUnrestrictedNetworking()غیرفعال شده باشد) - سوار کردن (بااستفاده از نمای سفارشی درخت سیستم فایل)
- PID
- کاربر
- UTS
درباره فضاهای نام Linux در Wikipedia یا در صفحه راهنمای مربوطه بیشتر بخوانید.
ارتباط میان پردازشی : IPC
Sandbox2 امکان تبادل داده‌های اختیاری بین «اجراکننده جعبه شنی» و Sandboxee غیرقابل‌اعتماد را فراهم می‌کند. این سوکت از پیام‌های «نوع-طول-مقدار» (TLV)، ارسال توصیف‌گرهای فایل، و تبادل اطلاعات کاربری ازطریق کدها و دستگیره‌ها پشتیبانی می‌کند.
Seccomp-BPF
Sandbox2 به seccomp-bpf متکی است که افزونه‌ای برای «حالت محاسبات امن» (seccomp) است و امکان استفاده از قوانین «فیلتر بسته برکلی» (BPF) را برای فیلتر کردن فراخوانی‌های سیستم فراهم می‌کند.
seccomp یکی از امکانات هسته Linux است که فراخوانی‌های سیستم یک فرایند را محدود می‌کند تا
فقط exit، sigreturn، read، و write مجاز باشد. اگر فرایندی تلاش کند
سیستم‌فراخوان دیگری را اجرا کند، آن فرایند بسته خواهد شد. افزونه seccomp-bpf انعطاف‌پذیری بیشتری نسبت به seccomp دارد. به‌جای مجاز کردن مجموعه ثابتی از syscallها،
seccomp-bpf برنامه BPF را روی داده‌های syscall اجرا می‌کند و بسته به
مقدار برگشتی برنامه، می‌تواند syscall را اجرا کند، syscall را رد کند و
مقدار ساختگی برگرداند، فرایند را خاتمه دهد، سیگنال تولید کند، یا به ردیاب اطلاع دهد.
Ptrace
سیستم‌فراخوان ptrace (ردیابی فرایند) عملکردی را ارائه می‌دهد که به فرایند ردیاب امکان می‌دهد اجرای فرایند ردیابی‌شده را مشاهده و کنترل کند. فرایند ردیاب پس‌از پیوستن، کنترل کامل ردیابی را دردست می‌گیرد. درباره ptrace در ویکی‌پدیا یا در صفحه راهنمای مربوطه بیشتر بخوانید.
خط‌مشی جعبه شنی
خط‌مشی جعبه شنی مهم‌ترین بخش جعبه شنی است، زیرا کنش‌هایی را که «جعبه‌شنی‌شده» می‌تواند و نمی‌تواند اجرا کند مشخص می‌کند. خط‌مشی جعبه امن ۲ بخش دارد:
- خط‌مشی Syscall
- راه‌اندازی فضای نام
خط‌مشی پیش‌فرض فراخوان سیستمی
خط‌مشی پیش‌فرض فراخوان‌های سیستمی را که همیشه خطرناک هستند مسدود می‌کند و بر خط‌مشی گسترش‌یافته ارائه‌شده توسط کاربر اولویت دارد.
خط‌مشی فراخوان سیستمی گسترده
خط‌مشی فراخوان سیستمی توسعه‌یافته را می‌توان بااستفاده از کلاس
PolicyBuilder
ما ایجاد کرد. این کلاس تعدادی قانون راحتی (مثلاً
AllowStaticStartup، AllowDynamicStartup، AllowOpen) تعریف می‌کند که می‌توان از آن‌ها برای
بهبود خوانایی خط‌مشی‌تان استفاده کرد.
در بیشتر موارد، بهتر است با
DefaultPolicyBuilder
(sapi::Sandbox2Config::DefaultPolicyBuilder()) شروع کنید که
PolicyBuilder را که ازقبل با خط‌مشی پایه برای کتابخانه‌های تک‌رشته‌ای معمولی پیکربندی شده است برمی‌گرداند و می‌توان آن را با قوانین بیشتر سفارشی‌سازی کرد
(مثل .AllowDynamicStartup() و .AddLibrariesForBinary() هنگام قرار دادن دودویی در جعبه امن). در Sandboxed API (SAPI)، DefaultPolicyBuilder() توسط
sapi::SandboxConfig::DefaultConfig() به‌همراه
sapi::SandboxConfig::DefaultFlags()،
sapi::SandboxConfig::DefaultEnvironmentVariables()، و
sapi::Sandbox2Config::DefaultLimits() استفاده می‌شود. ساختن PolicyBuilder به‌طور مستقیم
فقط باید زمانی استفاده شود که DefaultPolicyBuilder() قابل‌استفاده نباشد یا زمانی که
پیکربندی دقیق موردنیاز باشد.
اگر می‌خواهید فراخوان‌های سیستمی را بیشتر محدود کنید یا قوانین پیچیده‌تری را الزامی کنید، می‌توانید
کلان‌دستورهای BPF خام را با AddPolicyOnSyscall و AddPolicyOnSyscalls مشخص کنید. نمونه crc4 از این سازوکار برای محدود کردن متغیرهای مستقل برای فراخوانی‌های سیستم read، write، و close استفاده می‌کند.
به‌طور کلی، هرچه «خط‌مشی محیط امن» سخت‌گیرانه‌تر باشد، بهتر است زیرا سوءاستفاده از هرگونه آسیب‌پذیری موجود در کد توسط خط‌مشی محدود خواهد شد. اگر بتوانید دقیقاً مشخص کنید که کدام فراخوان‌های سیستمی و آرگومان‌ها برای عملکرد عادی برنامه لازم است، دراین‌صورت هر مهاجمی که از آسیب‌پذیری اجرای کد بهره‌برداری می‌کند نیز به همان محدودیت‌ها محدود می‌شود.
«خط‌مشی جعبه شنی» بسیار سخت‌گیرانه می‌تواند همه فراخوان‌های سیستمی را به‌جز خواندن و نوشتن در توصیف‌گرهای فایل ورودی و خروجی استاندارد رد کند. درون این محیط امن، برنامه می‌تواند ورودی را دریافت کند، آن را پردازش کند، و خروجی را برگرداند. بااین‌حال، اگر فرایند تلاش کند فراخوان سیستمی دیگری انجام دهد، به‌دلیل نقض خط‌مشی خاتمه می‌یابد. بنابراین، اگر فرایند به‌خطر بیفتد (اجرای کد توسط کاربر مخرب)، نمی‌تواند کاری بدتر از تولید برونداد بد انجام دهد (که اجراکننده و دیگران همچنان باید آن را به‌درستی مدیریت کنند).
راه‌اندازی فضای نام
از شیء PolicyBuilder برای راه‌اندازی نمای تکی Sandboxee از سیستم فایل نیز استفاده می‌شود. فایل‌های تکی (AddFile / AddFileAt)، کل دایرکتوری‌ها
(AddDirectory / AddDirectoryAt)، و همچنین فضای ذخیره‌سازی موقت (AddTmpfs)
را می‌توان در محیط Sandboxee نگاشت. علاوه‌براین،
از AddLibrariesForBinary می‌توان برای نگاشت خودکار همه کتابخانه‌های
موردنیاز برای فایل اجرایی پیوندشده پویا مشخص‌شده استفاده کرد.
پرچم‌های خط فرمان
هر خط‌مشی Sandbox2 را می‌توان با مشخص کردن یکی از پرچم‌های خط فرمان زیر غیرفعال کرد. این پرچم‌ها برای اهداف آزمایشی درنظر گرفته شده‌اند (مثلاً هنگام پالایش «خط‌مشی فراخوانی سیستم گسترش‌یافته»).
--sandbox2_danger_danger_permit_all--sandbox2_danger_danger_permit_all_and_log
اجراکننده جعبه شنی
مجری جعبه امن فرایندی است که خودش در جعبه امن قرار ندارد. این فرایند ردیاب ptrace است که به Sandboxee (فرایند ردیابی ptrace) متصل می‌شود. «مجری جعبه امن» همچنین یک نمونه پایشگر راه‌اندازی و اجرا می‌کند که «جعبه امن» را ردیابی می‌کند و اطلاعات وضعیت را ارائه می‌دهد.
Sandbox2 سه حالت اجرا را مجاز می‌کند: مستقل، Sandbox2 Forkserver، و Custom Forkserver. اگر از forkserver استفاده می‌کنید، Sandboxee به‌عنوان فرایند فرزند Sandbox Executor ایجاد می‌شود. این حالت‌ها به‌طور مفصل در اینجا توضیح داده شده‌اند.
جعبه شنی‌شده
«جعبه شنی» فرایندی است که در محیط محدود و جعبه شنی اجرا می‌شود که توسط «خط‌مشی جعبه شنی» تعریف شده است. «اجراکننده جعبه شنی» خط‌مشی را ازطریق IPC به «جعبه شنی» ارسال می‌کند. سپس Sandboxee خط‌مشی را اعمال می‌کند. هرگونه نقض خط‌مشی منجر به توقف فرایند خواهد شد، مگر اینکه به‌گونه‌ای دیگر پیکربندی شده باشد (به خط‌مشی جعبه شنی مراجعه کنید).