אישור ההרשאות אינו גבול אבטחה: מה באמת עוצר פקודה בקלוד קוד
מאת ירון דויטשר עודכן לאחרונה:
בגרסה 2.1.221 של קלוד קוד, שיצאה היום, יש שתי שורות ברשימת התיקונים ששוות עצירה. באחת, פקודה שהוסתרה בתוך תנאי [[ ]] של zsh עם ביטוי רגולרי הצליחה לרוץ בלי שבדיקת ההרשאות של כלי ה-Bash ראתה אותה. בשנייה, בדיקת ההרשאות של PowerShell בווינדוס טיפלה לא נכון בנתיבים שמכילים תווי גרשיים. בשני המקרים התיקון זהה: הפקודות האלה מבקשות אישור מעכשיו.
זו אינה פרצה דרמטית, ואין כאן סיבה לבהלה. אבל זו הזדמנות טובה להבין מה בדיקת ההרשאות עושה — ומה היא לא.
הבדיקה קוראת טקסט, לפני שמשהו רץ
מנגנון ההרשאות פועל לפני שהפקודה יוצאת לדרך, והוא עובד על מחרוזת: מנתח את טקסט הפקודה ומשווה אותו לכללים שהגדרתם. הניתוח הזה מתוחכם למדי. הוא מכיר מפרידים כמו &&, ||, ; ו-|, ודורש שכל תת-פקודה תתאים לכלל בנפרד — כך שכלל שמתיר פקודה אחת אינו מתיר אותה כשמשרשרים אחריה שנייה. הוא מפשיט עטיפות כמו xargs, ומסרב לאשר מראש עטיפות הרצה כמו watch או find עם הדגל -exec.
הוא גם מתוכנן להיכשל לכיוון הזהיר: כשהניתוח אינו מצליח לפרש פקודה במלואה, קלוד קוד מבקש אישור במקום להניח שהיא לקריאה בלבד. פקודה ארוכה מ-10,000 תווים תמיד תבקש אישור, מאותה סיבה בדיוק.
שתי התקלות שנסגרו היום הן המקרה ההפוך: תחביר שהפרסר לא פירש כראוי, ולכן התוצאה נטתה לכיוון האישור במקום לכיוון השאלה. זה הסיכון המובנה בכל בדיקה שקוראת מחרוזת — היא טובה בדיוק כמו הניתוח שמאחוריה.
מה נאכף בזמן ריצה
השכבה השנייה עובדת אחרת לגמרי. הסביבה המבודדת (sandbox) אינה קוראת את הפקודה כלל: היא מגדירה גבול שמערכת ההפעלה אוכפת על התהליך שרץ ועל כל תהליכי הבן שלו. במק זה נעשה דרך Seatbelt, ובלינוקס וב-WSL2 דרך bubblewrap.
התיעוד של אנתרופיק מנסח את ההבדל בצורה שקשה לשפר: החלטת ההרשאה נבדקת לפני שפקודה רצה ולפי מחרוזת הפקודה, ואילו גבול הבידוד מוחזק על התהליך עצמו — ולכן הוא תקף בלי קשר למה שהמודל בחר להריץ, וגם כשפקודה מאושרת עושה יותר ממה שהשם שלה מרמז.
בפועל הבידוד חוסם שני דברים: כתיבה מחוץ לתיקיית העבודה, וגישה לדומיינים שלא אישרתם. מפעילים אותו עם /sandbox ובוחרים מצב בלשונית Mode.
ושווה לדעת שיש שם שכבה שלישית שקטה: גם בתוך תיקיית העבודה, הבידוד חוסם כתיבה לקבצים שקלוד קוד עצמו טוען מהם הגדרות — .claude, .mcp.json, קובצי ההפעלה של המעטפת — כדי שפקודה לא תוכל להעניק לעצמה הרשאות להרצה הבאה. הפירוט המלא, כולל מה אי אפשר לפתוח בחזרה: הסביבה המבודדת בקלוד קוד.
ומה שחשוב לומר ביושר
הסביבה המבודדת אינה פתרון קסם, והתיעוד אומר זאת מפורשות: היא מקטינה סיכון ואינה גבול בידוד מלא. שלושה דברים ששווה לדעת לפני שנשענים עליה:
- מדיניות הקריאה הפתוחה: כברירת מחדל, פקודות בתוך הבידוד יכולות לקרוא כמעט את כל המחשב. התיעוד מציין במפורש שזה כולל קבצי סודות כמו התיקייה ~/.ssh וקובץ ההזדהות של AWS. אם זה מפריע — וזה צריך להפריע — מגדירים אותם תחת
sandbox.credentials - דומיין רחב מדי הוא דלת יציאה: הפרוקסי מחליט לפי שם המארח שהלקוח מבקש, בלי לפתוח את התעבורה המוצפנת. אישור גורף לדומיין גדול פותח נתיב אפשרי להוצאת מידע
- בווינדוס מקורי אין בידוד בכלל: הסביבה המבודדת רצה על מק, לינוקס ו-WSL2 בלבד. מי שמריצים קלוד קוד ישירות בווינדוס פשוט אינם מקבלים את השכבה הזאת, וכדי לקבל אותה צריך להריץ את קלוד קוד בתוך WSL2
הנקודה האחרונה חשובה במיוחד לקוראים ישראלים רבים שעובדים על ווינדוס, והיא כמעט לא מוזכרת בשום מקום.
שורה תחתונה
שתי השכבות אינן מתחרות זו בזו, והן עונות על שאלות שונות. אישור ההרשאות שואל “האם להריץ את הפקודה הזאת”, והוא מנגנון מצוין נגד טעויות. הבידוד קובע “מה הפקודה תוכל לגעת בו אחרי שהיא כבר רצה”, והוא זה שאינו תלוי בניסוח או בפרסר.
הצעד המעשי היום הוא קצר: מריצים claude update, מוודאים עם claude —version שהגרסה היא 2.1.221 ומעלה, ואם אתם נותנים לקלוד קוד לרוץ ארוך בלי שאתם יושבים מולו — מפעילים גם בידוד ולא מסתפקים בכללי הרשאות.
מכאן: לכוון את קלוד קוד מסביר איך בונים כללי הרשאות ו-hooks שאוכפים במקום לבקש, אוטומציה בטוחה מגדיר מה לעולם אינו רץ בלי אדם, והמדריך המלא לקלוד קוד הוא נקודת הפתיחה למי שרק מתחילים.