Sandboxed API توضیح داده شد

Sandboxed API (SAPI) بر روی پروژه Sandbox2 به خوبی تثبیت شده است. این صفحه معماری طراحی SAPI و مفاهیم کلیدی را توضیح می دهد.

بررسی اجمالی

SAPI برای ارائه ابزارهایی به توسعه دهندگان برای آماده سازی کتابخانه های C/C++ برای sandboxing و همچنین با API های لازم برای ارتباط با نسخه sandbox شده کتابخانه های C/C++ طراحی شده است.

این نمودار معماری یک کتابخانه C/C++ جعبه شنی SAPI را نشان می‌دهد:

نمودار SAPI

SAPI همچنین مقدماتی را برای همگام سازی حافظه دستی و خودکار (بر اساس ویژگی های اشاره گر سفارشی) (آرایه ها، ساختارها) بین کتابخانه های SAPI و کد میزبان فراهم می کند.

در نهایت، یک تراکنش‌های API سطح بالا نظارت بر کتابخانه‌های SAPI را قادر می‌سازد و در صورت شکست (مثلاً به دلیل نقض امنیتی، خرابی یا فرسودگی منابع) آنها را مجدداً راه‌اندازی می‌کند.

Sandbox2

پروژه منبع باز Sandbox2 توسط مهندسین امنیت Google توسعه و نگهداری می شود و هسته فناوری sandboxing است که توسط SAPI استفاده می شود. Sandbox2 شامل سه جزء اصلی است، Sandbox Policy ، Executor و Sandboxee .

خط مشی جعبه ایمنی

خط مشی sandbox محیط اجرای محدود را برای Sandboxed Library تعریف می کند. این امر با روشن کردن اینکه کدام یک از syscal ها را می توان اجرا کرد به دست می آید. SAPI از مکانیزم مشابه با Sandbox2 استفاده می کند، برای اطلاعات بیشتر در مورد نحوه طراحی و تعریف خط مشی جعبه ایمنی، به بخش Sandbox Policy و صفحه شروع به کار برای Sandbox2 مراجعه کنید.

SAPI از یک خط‌مشی پیش‌فرض استفاده می‌کند، یا می‌توانید با تعریف آن در یک فایل هدر sandbox.h و ارسال آن به عنوان یک آرگومان در قانون ساخت sapi_library از یک خط‌مشی sandbox اختصاصی استفاده کنید.

کتابخانه Sandboxed

این کتابخانه sandboxed C/C++ است که در محیط sandbox محدود ارائه شده توسط Sandbox2 اجرا خواهد شد. در نهایت، کتابخانه Sandboxed عملکرد مورد نیاز را که می‌تواند توسط کد میزبان مصرف شود، نشان می‌دهد.

کتابخانه Sandboxed با قانون ساخت sapi_library ساخته شده است، که در آن شما می توانید یک خط مشی جعبه ایمنی سفارشی را مشخص کنید که محیط اجرای محدود را تعریف می کند. بسته به کتابخانه، ممکن است مجبور شوید کدهای پوشه یا خرد بنویسید (به libcurl مراجعه کنید)، اما از شما انتظار نمی‌رود که کد منبع کتابخانه C/C++ را هنگام آماده‌سازی نسخه SAPI تغییر دهید.

SAPI Object و RPC Stub

SAPI Object یک شیء ++C است که API کتابخانه Sandboxed را در معرض دید قرار می دهد. تماس‌ها را از کد میزبان به RPC Stub ارسال می‌کند که در کتابخانه SAPI به همراه کتابخانه Sandboxed تعبیه شده است.

این دو عنصر به طور خودکار توسط سیستم ساخت و با استفاده از قانون ساخت sapi_library() تولید می شوند. SAPI از دو سیستم ساخت، Bazel و CMake گوگل پشتیبانی می کند.

کد میزبان

کد میزبان چیزی است که منطق ارائه شده توسط کتابخانه SAPI را پیاده سازی می کند. این چیزی است که در غیر این صورت نسخه جعبه نشده کتابخانه C/C++ را مصرف می کند. به این ترتیب، کد میزبان، توابع صادر شده توسط کتابخانه SAPI را فراخوانی می کند و داده ها را به جعبه شنی ارسال می کند و داده ها را از آن دریافت می کند.

کد میزبان باید برای استفاده از کتابخانه SAPI تطبیق داده شود. مهمتر از همه، فراخوانی توابع کتابخانه امکان پذیر نیست، زیرا کتابخانه در یک فرآیند سندباکس جداگانه زندگی می کند. بنابراین، SAPI ابزارهایی را فراهم می کند که یک شی SAPI ایجاد می کند که فراخوانی های یک کتابخانه SAPI را پراکسی می کند.

مفاهیم

قوانین ساخت Bazel

پروژه SAPI دو قانون ساخت Bazel را برای سندباکس کردن یک کتابخانه C/C++ ارائه می‌کند:

  • sapi_library() - تمام خروجی‌هایی را ایجاد می‌کند که برای داشتن کتابخانه C/C++ به عنوان Sandbox2 Sandboxee لازم است. خروجی ساخت می تواند به عنوان یک وابستگی برای قانون cc_binary() استفاده شود که برای ساخت کد میزبان باینری استفاده می شود.
  • sapi_interface() – هدر را به صورت خودکار تولید می کند که می تواند در کد باینری میزبان گنجانده شود.

برای توضیح جامع تر در مورد قوانین ساخت، به قوانین ساخت مراجعه کنید.

متغیرها

SAPI تعدادی نوع خاص به نام انواع SAPI ارائه می دهد که توصیه می کنیم در کد میزبان استفاده کنید. دلیل اصلی نیاز به انواع SAPI به دلیل فرآیند و در نتیجه حافظه جداسازی بین کد میزبان و کتابخانه Sandboxed است.

برای توضیح جامع تر درباره این موضوع و مروری بر برخی از انواع متداول SAPI، به متغیرها مراجعه کنید.

معاملات

همانطور که در بالا توضیح داده شد، هر فراخوانی API به یک کتابخانه Sandboxed از یک لایه RPC منتقل می شود. برای اینکه بتوانید یک خرابی در این لایه را مدیریت کنید، باید مدیریت خطای مناسب را پیاده سازی کنید. ماژول تراکنش SAPI مکانیزم لازم را برای اطمینان از اینکه همه تماس‌های یک کتابخانه Sandboxed بدون هیچ مشکلی در سطح RPC تکمیل می‌شوند یا با خطای مربوطه بازگردانده می‌شوند، فراهم می‌کند.

برای توضیح جامع تر درباره این موضوع، به تراکنش ها مراجعه کنید.

شروع شدن

صفحه شروع ما را بخوانید تا اولین پروژه Sandboxed API خود را راه اندازی کنید.

،

Sandboxed API (SAPI) بر روی پروژه Sandbox2 به خوبی تثبیت شده است. این صفحه معماری طراحی SAPI و مفاهیم کلیدی را توضیح می دهد.

بررسی اجمالی

SAPI برای ارائه ابزارهایی به توسعه دهندگان برای آماده سازی کتابخانه های C/C++ برای sandboxing و همچنین با API های لازم برای ارتباط با نسخه sandbox شده کتابخانه های C/C++ طراحی شده است.

این نمودار معماری یک کتابخانه C/C++ جعبه شنی SAPI را نشان می‌دهد:

نمودار SAPI

SAPI همچنین مقدماتی را برای همگام سازی حافظه دستی و خودکار (بر اساس ویژگی های اشاره گر سفارشی) (آرایه ها، ساختارها) بین کتابخانه های SAPI و کد میزبان فراهم می کند.

در نهایت، یک تراکنش‌های API سطح بالا نظارت بر کتابخانه‌های SAPI را قادر می‌سازد و در صورت شکست (مثلاً به دلیل نقض امنیتی، خرابی یا فرسودگی منابع) آنها را مجدداً راه‌اندازی می‌کند.

Sandbox2

پروژه منبع باز Sandbox2 توسط مهندسین امنیت Google توسعه و نگهداری می شود و هسته فناوری sandboxing است که توسط SAPI استفاده می شود. Sandbox2 شامل سه جزء اصلی است، Sandbox Policy ، Executor و Sandboxee .

خط مشی جعبه ایمنی

خط مشی sandbox محیط اجرای محدود را برای Sandboxed Library تعریف می کند. این امر با روشن کردن اینکه کدام یک از syscal ها را می توان اجرا کرد به دست می آید. SAPI از مکانیزم مشابه با Sandbox2 استفاده می کند، برای اطلاعات بیشتر در مورد نحوه طراحی و تعریف خط مشی جعبه ایمنی، به بخش Sandbox Policy و صفحه شروع به کار برای Sandbox2 مراجعه کنید.

SAPI از یک خط‌مشی پیش‌فرض استفاده می‌کند، یا می‌توانید با تعریف آن در یک فایل هدر sandbox.h و ارسال آن به عنوان یک آرگومان در قانون ساخت sapi_library از یک خط‌مشی sandbox اختصاصی استفاده کنید.

کتابخانه Sandboxed

این کتابخانه sandboxed C/C++ است که در محیط sandbox محدود ارائه شده توسط Sandbox2 اجرا خواهد شد. در نهایت، کتابخانه Sandboxed عملکرد مورد نیاز را که می‌تواند توسط کد میزبان مصرف شود، نشان می‌دهد.

کتابخانه Sandboxed با قانون ساخت sapi_library ساخته شده است، که در آن شما می توانید یک خط مشی جعبه ایمنی سفارشی را مشخص کنید که محیط اجرای محدود را تعریف می کند. بسته به کتابخانه، ممکن است مجبور شوید کدهای پوشه یا خرد بنویسید (به libcurl مراجعه کنید)، اما از شما انتظار نمی‌رود که کد منبع کتابخانه C/C++ را هنگام آماده‌سازی نسخه SAPI تغییر دهید.

SAPI Object و RPC Stub

SAPI Object یک شیء ++C است که API کتابخانه Sandboxed را در معرض دید قرار می دهد. تماس‌ها را از کد میزبان به RPC Stub ارسال می‌کند که در کتابخانه SAPI به همراه کتابخانه Sandboxed تعبیه شده است.

این دو عنصر به طور خودکار توسط سیستم ساخت و با استفاده از قانون ساخت sapi_library() تولید می شوند. SAPI از دو سیستم ساخت، Bazel و CMake گوگل پشتیبانی می کند.

کد میزبان

کد میزبان چیزی است که منطق ارائه شده توسط کتابخانه SAPI را پیاده سازی می کند. این چیزی است که در غیر این صورت نسخه جعبه نشده کتابخانه C/C++ را مصرف می کند. به این ترتیب، کد میزبان، توابع صادر شده توسط کتابخانه SAPI را فراخوانی می کند و داده ها را به جعبه شنی ارسال می کند و داده ها را از آن دریافت می کند.

کد میزبان باید برای استفاده از کتابخانه SAPI تطبیق داده شود. مهمتر از همه، فراخوانی توابع کتابخانه امکان پذیر نیست، زیرا کتابخانه در یک فرآیند سندباکس جداگانه زندگی می کند. بنابراین، SAPI ابزارهایی را فراهم می کند که یک شی SAPI ایجاد می کند که فراخوانی های یک کتابخانه SAPI را پراکسی می کند.

مفاهیم

قوانین ساخت Bazel

پروژه SAPI دو قانون ساخت Bazel را برای سندباکس کردن یک کتابخانه C/C++ ارائه می‌کند:

  • sapi_library() - تمام خروجی‌هایی را ایجاد می‌کند که برای داشتن کتابخانه C/C++ به عنوان Sandbox2 Sandboxee لازم است. خروجی ساخت می تواند به عنوان یک وابستگی برای قانون cc_binary() استفاده شود که برای ساخت کد میزبان باینری استفاده می شود.
  • sapi_interface() – هدر را به صورت خودکار تولید می کند که می تواند در کد باینری میزبان گنجانده شود.

برای توضیح جامع تر در مورد قوانین ساخت، به قوانین ساخت مراجعه کنید.

متغیرها

SAPI تعدادی نوع خاص به نام انواع SAPI ارائه می دهد که توصیه می کنیم در کد میزبان استفاده کنید. دلیل اصلی نیاز به انواع SAPI به دلیل فرآیند و در نتیجه حافظه جداسازی بین کد میزبان و کتابخانه Sandboxed است.

برای توضیح جامع تر درباره این موضوع و مروری بر برخی از انواع متداول SAPI، به متغیرها مراجعه کنید.

معاملات

همانطور که در بالا توضیح داده شد، هر فراخوانی API به یک کتابخانه Sandboxed از یک لایه RPC منتقل می شود. برای اینکه بتوانید یک خرابی در این لایه را مدیریت کنید، باید مدیریت خطای مناسب را پیاده سازی کنید. ماژول تراکنش SAPI مکانیزم لازم را برای اطمینان از اینکه همه تماس‌های یک کتابخانه Sandboxed بدون هیچ مشکلی در سطح RPC تکمیل می‌شوند یا با خطای مربوطه بازگردانده می‌شوند، فراهم می‌کند.

برای توضیح جامع تر درباره این موضوع، به تراکنش ها مراجعه کنید.

شروع شدن

صفحه شروع ما را بخوانید تا اولین پروژه Sandboxed API خود را راه اندازی کنید.