קיס קוק קורא לארגון עבודה טוב יותר בלינוקס בנוגע לתיקוני באגים

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

לדברי קיס, תהליך הטיפול בשגיאות הליבה עוקף ו בליבה חסרים לפחות 100 מפתחים נוספים לעבוד בצורה מתואמת בתחום זה. מציינים גם כי מפתחי גרעינים מרכזיים מתקנים באגים באופן קבוע, אך אין ערובה לכך שהתיקונים הללו יועברו לגרסאות גרעין של צד שלישי.

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

מפתחי גרעינים במעלה הזרם יכולים לתקן באגים, אך אין להם שליטה על מה שספק במורד הזרם בוחר לשלב במוצרים שלהם. משתמשי קצה יכולים לבחור את המוצרים שלהם, אך בדרך כלל אין להם שליטה באילו באגים מתקנים או באיזה גרעין משתמשים (בעיה בפני עצמה). בסופו של דבר, הספקים אחראים לשמור על בטיחות ליבות המוצרים שלהם.

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

כדי להחמיר את המצב, תיקוני פגיעות פוטנציאליים רבים אינם מתויגים עם מזהי CVE או אינם מקבלים מזהה CVE זמן מה לאחר שחרור התיקון.

בסביבה כזו, קשה מאוד ליצרנים להפריד תיקונים קלים מבעיות אבטחה גדולות. על פי הסטטיסטיקה, יותר מ -40% מהפגיעות מוסרות לפני הקצאת CVE, ובממוצע העיכוב בין שחרור תיקון לבין הקצאת CVE הוא שלושה חודשים (כלומר, בהתחלה, נתפס פתרון כטעות נפוצה,

כתוצאה מכך, ללא סניף נפרד עם תיקונים לפגיעויות ואי קבלת מידע אודות הקשר לאבטחת בעיה זו או אחרת, יצרנים של מוצרים מבוססי לינוקס לינוקס צריכים להעביר ללא הרף את כל התיקונים של הענפים היציבים החדשים. אך עבודה זו היא עתירת עבודה ומתמודדת עם התנגדות מצד חברות בשל חשש משינויים רגרסיביים שעלולים לשבש את פעולתו התקינה של המוצר.

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

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

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

מקור: https://security.googleblog.com


תוכן המאמר עומד בעקרונותינו של אתיקה עריכתית. כדי לדווח על שגיאה לחץ כאן.

היה הראשון להגיב

השאירו את התגובה שלכם

כתובת הדוא"ל שלך לא תפורסם. שדות חובה מסומנים *

*

*

  1. אחראי לנתונים: מיגל אנחל גטון
  2. מטרת הנתונים: בקרת ספאם, ניהול תגובות.
  3. לגיטימציה: הסכמתך
  4. מסירת הנתונים: הנתונים לא יועברו לצדדים שלישיים אלא בהתחייבות חוקית.
  5. אחסון נתונים: מסד נתונים המתארח על ידי Occentus Networks (EU)
  6. זכויות: בכל עת תוכל להגביל, לשחזר ולמחוק את המידע שלך.