🔐 פרק 7

אבטחה, הרשאות ו-Sandbox ברמת הקרנל

ארכיטקטורת האבטחה של Grok CLI בנויה משלוש שכבות הגנה משלימות:

1. מצבי הרשאה (Permission Modes): קובעים את רמת המעורבות שלכם ואת תדירות בקשות האישור עבור פעולות שונות.
2. כללי הרשאה מפורשים (Explicit Rules): מגדירים במדויק אילו כלים, פקודות ונתיבים מותרים (allow), אילו דורשים שאלה (ask), ואילו חסומים לחלוטין (deny).
3. בידוד Sandbox ברמת הקרנל: מגביל גישה למערכת הקבצים ולרשת ברמת מערכת ההפעלה (באמצעות Landlock בלינוקס ו-Seatbelt ב-macOS).

#חמשת מצבי ההרשאה

Grok CLI תומך בחמישה מצבי הרשאה שונים:

#הגדרת מצב הרשאה

משורת הפקודה:

# הרצה במצב אישור אוטומטי מלא
grok --always-approve
# כינוי מקוצר
grok --yolo
# קביעת מצב מפורש
grok --permission-mode acceptEdits

בתוך ה-TUI: מקש Ctrl+O או Shift+Tab מעבירים למצב אישור אוטומטי, וכן הפקודות /always-approve ו-/auto.

בקובץ התצורה ~/.grok/config.toml:

[ui]
permission_mode = "acceptEdits"

ארגונים יכולים לנעול את האפשרות לשימוש ב-always-approve בקובץ requirements.toml המנוהל:

[ui]
disable_bypass_permissions_mode = true

#סדר בדיקת הבקשות (Pipeline)

כאשר המודל מבקש להפעיל כלי או פקודה, הבקשה עוברת צינור בדיקה מוגדר ומסודר:

[בקשת כלי מהמודל]
       ↓
1. בדיקת הוק PreToolUse (יכול לחסום מיידית)
       ↓
2. בדיקת כללי הרשאה מפורשים: deny -> ask -> allow (deny תמיד מנצח)
       ↓
3. בדיקת אישורים שנשמרו לפרויקט הנוכחי (remember_tool_approvals)
       ↓
4. אישור אוטומטי מובנה עבור קריאה ופקודות Shell לקריאה בלבד
       ↓
5. בדיקת מדיניות מצב ההרשאות הנוכחי (לשאול, לאשר או לדחות)

במצב always-approve שלבים 3 ו-5 מאושרים אוטומטית, אך כללי deny, הוקים מסוג PreToolUse, וכללי ask מפורשים על מקטעי Shell עדיין נאכפים במלואם.

#הגדרת כללי הרשאות מפורשים (Rules)

כללים מוגדרים בקובץ .grok/config.toml של הפרויקט או בקובץ הגלובלי ~/.grok/config.toml:

[permission]
# פקודות מאושרות תמיד ללא שאלה
allow = [
  "Bash(npm test)",
  "Bash(git status)",
  "Bash(cargo check)"
]

# חסימה מוחלטת של פקודות ונתיבים רגישים
deny = [
  "Bash(rm -rf *)",
  "Bash(git push --force*)",
  "Read(**/.env*)",
  "Read(**/*.pem)",
  "Read(**/*.key)",
  "Write(.github/**)"
]

תחביר הכלל הוא ToolPrefix(glob). קידומות הכלים המרכזיות כוללות: Bash, Edit, Write, Read, Grep, WebFetch ו-MCPTool.

בדפוסים: * תואם מקטע יחיד, ו-** תואם עץ תיקיות רקורסיבי. בכללי Bash, התו * תופס גם רווחים וארגומנטים.

ניתן להעביר כללים גם משורת הפקודה:

grok -p "Run tests and cleanup" --allow "Bash(npm test)" --deny "Bash(rm*)"

#אילו פעולות מאושרות אוטומטית לקריאה

1. כלי קריאה מובנים: read_file, list_dir, grep, web_search, todo_write, הפעלת סקילז וניהול סוכני משנה.
2. פקודות Shell לקריאה בלבד: פקודות כמו ls, cat, pwd, git status, git log, git diff, rg (ללא הדגל --pre) ו-kubectl get.

Grok CLI מפרק פקודות Shell מורכבות המחוברות באמצעות &&, ||, ; או צינורות (|), ובודק כל מקטע בנפרד. שרשור כמו ls && rm -rf / יאשר את ה-ls אך יעצור ויבקש אישור על פקודת ה-rm.

פקודות כמו tee אינן מוגדרות כפקודות קריאה, מכיוון שהן מבצעות כתיבה לדיסק.

#בידוד באמצעות Sandbox ברמת הקרנל

מנגנון ה-Sandbox מבודד את תהליכי הסוכן ותהליכי הבן שלו ברמת הקרנל של מערכת ההפעלה:

grok --sandbox workspace
grok --sandbox read-only
grok --sandbox strict

#פרופילי Sandbox מובנים

חסימת רשת לתהליכי בן פועלת בלינוקס ודורשת התקנה של bubblewrap. אם מופעל Sandbox בלינוקס ללא bubblewrap, המערכת תסרב לעלות כדי למנוע ריצה לא מוגנת.

#הגדרת פרופיל מותאם אישית ב-sandbox.toml

ניתן להגדיר פרופיל ייעודי ב-~/.grok/sandbox.toml או ב-.grok/sandbox.toml:

[profiles.secure-project]
extends = "workspace"
restrict_network = true
deny = ["**/.env", "**/*.pem", "secrets/**"]

והפעלתו באמצעות: grok --sandbox secure-project.

#המלצות מעשיות לסביבת עבודה בטוחה

1. במחשב הפיתוח האישי: עבדו במצב default או acceptEdits, והגדירו כללי deny על קובצי סודות (.env, מפתחות SSH) ועל פקודות מחיקה גורפות (rm -rf).
2. בסביבות אוטומציה ו-CI: השתמשו ב---always-approve או --yolo, אך הגדירו תמיד סנדבוקס מבודד וכללי deny קשיחים.
3. סקירת שינויים: השתמשו ב-git diff לפני ביצוע Commit כדי לוודא שכל השינויים שנכתבו תואמים את כוונתכם.

בפרק הבא נלמד כיצד להרחיב את המערכת באמצעות Hooks להאזנה לאירועים ואכיפת מדיניות אוטומטית.