ה-Sandboxed API (SAPI) מבוסס על פרויקט Sandbox2 הוותיק. בדף הזה מוסברת ארכיטקטורת העיצוב של SAPI ומושגים מרכזיים.
סקירה כללית
SAPI נועד לספק למפתחים כלים להכנת ספריות C/C++ להרצה בארגז חול, וכן ממשקי API הנדרשים לתקשורת עם גרסת ארגז החול של ספריות C/C++.
בתרשים הזה מוצגת הארכיטקטורה של ספריית C/C++ בארגז החול של SAPI:
SAPI מספק גם פרימיטיבים עבור סנכרון ידני ואוטומטי (על סמך מאפייני מצביע מותאמים אישית) לסנכרון זיכרון (מערכים, מבנים) בין ספריות ה-SAPI לקוד המארח.
לבסוף, ממשק API ברמה גבוהה לעסקאות מאפשר לעקוב אחר ספריות SAPI, ולהפעיל אותן מחדש אם הן נכשלות (לדוגמה, עקב הפרות אבטחה, קריסות או מיצוי משאבים).
Sandbox2
פרויקט הקוד הפתוח Sandbox2 פותח ומתוחזק על ידי מהנדסי האבטחה של Google, והוא הטכנולוגיה העיקרית של הרצה בארגז חול (sandboxing) שמשמשת את SAPI. Sandbox2 כולל שלושה רכיבים עיקריים: מדיניות Sandbox, הפעלה ו-Sandboxee.
מדיניות בנושא Sandbox
מדיניות Sandbox מגדירה את סביבת הביצוע המוגבלת עבור 'הספרייה בארגז החול'. כדי לעשות זאת, צריך להבהיר אילו syscalls ניתן לבצע. SAPI משתמש באותו מנגנון כמו Sandbox2. מידע נוסף על תכנון והגדרה של מדיניות Sandbox זמין בקטע 'מדיניות Sandbox' ובדף 'תחילת העבודה' עבור Sandbox2.
SAPI משתמש במדיניות ברירת מחדל. לחלופין, ניתן להשתמש במדיניות ייעודית ל-Sandbox על ידי הגדרתה בקובץ הכותרת sandbox.h והעברתה כארגומנט בכלל ה-build של sapi_library.
ספרייה בארגז חול
זוהי ספריית C/C++ בארגז חול שתבוצע בסביבת Sandbox המוגבלת המסופקת על ידי Sandbox2. בסופו של דבר, הספרייה Sandboxed חושפת את הפונקציונליות הנדרשת הניתנת לצריכה באמצעות קוד המארח.
הספרייה בארגז החול נוצרת באמצעות כלל ה-build sapi_library, שבו אפשר להגדיר מדיניות מותאמת אישית לארגז חול שמגדירה את סביבת הביצוע המוגבלת. בהתאם לספרייה, ייתכן שתצטרכו לכתוב קוד wrapper או קוד stub (ראו libcurl), אבל אין צורך לשנות את קוד המקור של ספריית C/C++ במהלך הכנת גרסת ה-SAPI.
אובייקט SAPI ו-Stub של RPC
אובייקט SAPI הוא אובייקט C++ שחושף את ה-API של הספרייה Sandboxed. היא מעבירה קריאות מ-Host Code אל RPC Stub, שמוטמע ב-SAPI Library יחד עם Sandboxed Library.
שני הרכיבים האלה נוצרים באופן אוטומטי על ידי מערכת ה-build באמצעות כלל ה-build sapi_library(). SAPI תומך בשתי מערכות build, Bazel ו-CMake של Google.
קוד המארח
קוד המארח הוא מה שמיישם את הלוגיקה שסופקה על ידי ספריית SAPI. זו הגרסה שאמורה לצרוך את הגרסה ללא ארגז חול (sandbox) של ספריית C/C++. לכן, קוד המארח קורא לפונקציות שמיוצאות על ידי ספריית SAPI, מעבירות נתונים ל-Sandbox ומקבלים נתונים ממנו.
צריך להתאים את קוד המארח כדי להשתמש בספריית SAPI. ההגבלה המשמעותית ביותר היא שלא ניתן לקרוא לפונקציות של הספרייה מפני שהספרייה פועלת בתהליך נפרד בארגז חול. לכן, SAPI מספק כלים ליצירת אובייקט SAPI שמבצע קריאות לספריית SAPI.
מושגים
כללי build של Bazel
פרויקט SAPI מספק שני כללי build של Bazel להרצה בארגז חול (sandboxing) של ספריית C/C++:
sapi_library()– יוצר את כל הפלטים הנחוצים כדי להעביר את ספריית C/C++ לארגז החול בתור Sandbox2 Sandbox. פלט ה-build יכול לשמש כתלות בכללcc_binary()שמשמש לבניית הקוד הבינארי של קוד המארח.sapi_interface()– יוצר באופן אוטומטי את הכותרת שניתן לכלול בקובץ הבינארי של קוד המארח.
להסבר מקיף יותר על כללי ה-build, אפשר לעיין בכללי ה-Build.
משתנים
SAPI מספק כמה סוגים מיוחדים, שנקראים סוגי SAPI, שבהם מומלץ להשתמש בקוד המארח. הסיבה העיקרית לכך שיש צורך בסוגי SAPI היא התהליך, ולכן הבידוד של קוד המארח בין קוד המארח לבין הספרייה בארגז החול.
להסבר מקיף יותר בנושא הזה וסקירה כללית של כמה סוגי SAPI נפוצים, אפשר לעיין במאמר משתנים.
עסקאות
כפי שהוסבר למעלה, כל קריאה ל-API לספרייה Sandboxed מועברת מעל שכבת RPC. כדי לטפל בכשל בשכבה הזו, צריך ליישם טיפול מתאים בשגיאות. המודול עסקה של SAPI מספק את המנגנון הדרוש כדי לוודא שכל הקריאות לספרייה ב-Sandboxed הושלמו ללא בעיות ברמת ה-RPC, או שהן מוחזרות עם שגיאה רלוונטית.
הסבר מקיף יותר בנושא הזה זמין במאמר עסקאות.
תחילת העבודה
קרא את הדף תחילת העבודה כדי להגדיר את הפרויקט הראשון שלך ב-Sandboxed API.