פרסום מקורי: . תיקון המאמר האנגלי: . תרגום ובדיקה טכנית: .
בדיקת גישה מועילה עוקבת אחר בקשה עד לחשבון במערכת ההפעלה שמבצע אותה בפועל. הידיעה מי עבר אימות זהות ומה המדיניות התכוונה לאפשר היא רק חלק מהראיות הדרושות.
הודעת האבטחה של Tailscale מ־13 ביולי 2026 מתארת בעיה בחיפוש חשבון משתמש ב־Linux באמצעות getent. היא השפיעה על תצורות Tailscale SSH שהשתמשו בהגבלה autogroup:nonroot. התיקון המתועד לבעיה המסוימת הזו הוא גרסה 1.98.9. זהו מספר גרסת התיקון ההיסטורי, לא המלצה להסתפק כיום בגרסה ישנה: בהתקנה פעילה יש להיעזר במסלול העדכון הנתמך של הספק ולבדוק גם הודעות אבטחה מאוחרות יותר.
לפירוט המחשבים שהושפעו ולהנחיות עדכון, ראו את מדריך המנהלים המתוקן על TS-2026-009 באנגלית. רשימת הבדיקה שלהלן היא הנחיה כללית לבדיקת הרשאות, לא שחזור של המימוש הפנימי של Tailscale.
מפו את הזהות בכל מעבר בין רכיבים
בשירות גישה מרחוק, תעדו מי הגורם שעבר אימות זהות, לאיזה חשבון יעד הוא ביקש להתחבר, איזה חשבון אושר במדיניות, לאיזו זהות מקומית תורגמה הבקשה ובאיזו זהות החיבור פועל לבסוף. שימו לב למקומות שבהם שם משתמש הופך למזהה מספרי או מועבר לרכיב אחר.
השאלה ממוקדת: האם שינוי בייצוג הזהות עלול לשנות את החשבון שבו משתמשים אחרי שכבר התקבלה החלטת ההרשאה? אל תקבלו התחברות מוצלחת כהוכחה שנבחר החשבון שהתכוונתם אליו.
בקשו ראיות, לא רק צילום של המדיניות
- כוונת המדיניות: אילו גורמים רשאים לגשת לאילו מחשבים וחשבונות מקומיים? הבדילו בין רשימת חשבונות מפורשת לבין קבוצות רחבות או כללי בחירה אחרים.
- איתור הזהות המקומית: איזה רכיב מחפש את חשבון המשתמש? איך נדחים קלט בלתי צפוי, כישלון בחיפוש ותוצאה שאפשר לפרש ביותר מדרך אחת?
- יצירת החיבור: מה קובע את המשתמש הסופי, את הקבוצות ואת שאר ההרשאות שלו? היכן נבדק שהוא אכן החשבון שאושר?
- ראיות לבדיקה: איזו תצורה, גרסת מימוש ותוצאת בדיקה תומכות בכל תשובה? סמנו ראיות חסרות כעניין שעדיין לא הוכרע, במקום להניח שברירת המחדל מאובטחת.
הגדירו מראש מה בדיקת רגרסיה חייבת להוכיח
בדיקת רגרסיה נועדה לוודא שהבעיה אינה חוזרת ושהתנהגות תקינה לא נפגעה. בסביבה מבודדת שבבעלותכם, או שיש לכם הרשאה לבדוק, הגדירו את התוצאות הצפויות לפני הבדיקה: חיבורים מורשים פועלים בזהות המיועדת; בחירה בחשבון אסור נכשלת; ובקשות פגומות או עמומות נדחות במקום לקבל גישה. כללו גם התחברות רגילה שאמורה להצליח, כדי ששינוי שחוסם הכול לא ייחשב בטעות לתיקון מלא.
בדקו בנפרד את החלטת המדיניות ואת הזהות שבה החיבור פועל בפועל. תעדו את הגרסה והתצורה שנבדקו. אלה קריטריונים לקבלת תיקון, לא הוראות לשחזור ניצול במחשב ייצור. לא בוצעה בדיקת מערכת או התחברות במסגרת הכנת התרגום.
הפרידו בין הקשחה לבין הרשאה נכונה
הדגל no_new_privs ב־Linux מגביל קבלת הרשאות נוספות בעת הפעלת תוכנית באמצעות execve. הוא אינו מסיר הרשאות שכבר קיימות ואינו מונע כל דרך אחרת לשנות הרשאות. תיעוד ליבת Linux מפרט את הגבולות האלה. אם חיבור התחיל בזהות בעלת הרשאות שלא הייתה אמורה להיבחר, עדיין צריך לתקן את ליקוי ההרשאה עצמו.
דוגמת ה־Go שהוסרה הציבה את NoNewPrivs בתוך syscall.Credential, אבל השדה הזה אינו קיים ב־ממשק המתועד. לא מוצעת כאן דוגמת קוד חלופית להפעלת תהליכים בהקשר אבטחתי. קוד כזה דורש בדיקה ובחינה המותאמות לפלטפורמה, לא הבטחה כללית ששורת קוד אחת מספקת הגנה.
סיימו עם אחראי ועם אימות התוצאה
לכל התקנה רלוונטית, תעדו מי אחראי לטיפול, איזו הודעת ספק חלה עליה, מהו מסלול העדכון, איזו גרסה רצה אחרי השינוי ואילו שאלות על בקרת הגישה עדיין פתוחות. הפרידו בין החובה להתקין תיקון ספק לבין עבודת הקשחה נוספת.
התוצאה הרצויה היא ראיות לכך שהמעבר לחשבון היעד שומר על ההרשאה שהתכוונתם לתת — לא רק סימון ״העדכון בוצע״ ברשימה.
מקור: המאמר המקורי באנגלית, בגרסתו המתוקנת. תרגום לעברית עבור The Useful Byte.