לינוקס: הסרת מאגר נעילה /dev/random

/dev/random, מחולל מספרים פסאודו-אקראי מאובטח מבחינה קריפטוגרפית (CSPRNG), ידוע כבעל בעיה מעצבנת אחת: חסימה. מאמר זה מסביר כיצד ניתן לפתור זאת.

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

אנדי לוטומירסקי פרסם את הגרסה השלישית של התיקון בסוף דצמבר. הוא תורם "שני שינויים סמנטיים גדולים בממשקי API אקראיים של לינוקס". התיקון מוסיף דגל חדש של GRND_INSECURE לקריאת המערכת getrandom() (אם כי לוטומירסקי מתייחס אליו כ-getentropy(), אשר מיושם ב-glibc באמצעות getrandom() עם דגלים קבועים); הדגל הזה גורם לקריאה להחזיר תמיד את כמות הנתונים המבוקשת, אך מבלי להבטיח שהנתונים הם אקראיים. הקרנל פשוט יעשה כמיטב יכולתו לייצר את הנתונים האקראיים הטובים ביותר שיש לו בזמן הנתון. "כנראה הדבר הטוב ביותר לעשות הוא לקרוא לזה 'לא בטוח' (לא מאובטח) כדי למנוע שימוש ב-API הזה לדברים שזקוקים לאבטחה."

הטלאים מסירים גם את הבריכה החוסמת. הליבה שומרת כרגע על שני מאגרי נתונים אקראיים, האחד מתאים ל-/dev/random והשני ל-/dev/urandom, כמתואר בזה статье 2015. מאגר החסימה הוא המאגר עבור /dev/random; קריאות עבור אותו מכשיר יחסמו (הכוונה לשמו) עד לאיסוף אנטרופיה "מספיק" מהמערכת כדי לספק את הבקשה. קריאות נוספות מקובץ זה נחסמות גם אם אין מספיק אנטרופיה במאגר.

הסרת מאגר הנעילה פירושה שקריאה מ-/dev/random מתנהגת כמו getrandom() עם דגלים מוגדרים לאפס (והופכת את הדגל GRND_RANDOM ל-noop). לאחר אתחול מחולל המספרים האקראיים (CRNG) ההצפנה, קריאה מ-/dev/random וקריאות ל-getrandom(...,0) לא תחסום ותחזיר את הכמות המבוקשת של נתונים אקראיים.

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

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

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

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

סטפן מולר הציע את הסט שלו טלאים עבור Linux Random Number Generator (LRNG) (ששוחררה כעת גרסה 26) יכולה להיות דרך לספק מספרים אקראיים אמיתיים עבור יישומים הזקוקים לכך. LRNG "תואם באופן מלא להנחיות SP800-90B על מקורות אנטרופיה המשמשים ליצירת ביטים אקראיים", מה שהופך אותו לפתרון לבעיית התקנים הממשלתיים.
מתיו גארט התנגד למונח "נתונים אקראיים אמיתיים", וציין כי ניתן לעצב באופן עקרוני את המכשירים שנדגמו במדויק מספיק כדי להפוך אותם לניתנים לחיזוי: "אנחנו לא דוגמים כאן אירועים קוונטיים".

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

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

כפי שאמר לוטומירסקי: "זה לא פותר את הבעיה. אם שני משתמשים שונים יפעילו תוכניות מטופשות כמו gnupg, הם פשוט ירוקנו אחד את השני. אני רואה שיש כרגע שתי בעיות עיקריות עם /dev/random: הוא נוטה ל-DoS (כלומר דלדול משאבים, השפעה זדונית או משהו דומה), ומכיוון שלא נדרשות הרשאות כדי להשתמש בו, הוא גם נוטה לשימוש לרעה. Gnupg טועה, זו קריסה מוחלטת. אם נוסיף ממשק חדש ללא פריבילגיה ש-gnupg ותוכנות דומות ישתמשו בו, נפסיד שוב."

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

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

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

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

"הקרנל לא יכול לתת ערבויות כלשהן אם מקור הרעש אופיין כראוי. הדבר היחיד שמפתח GPG או OpenSSL יכול לקבל הוא תחושה עמומה ש-TRUERANDOM הוא "טוב יותר", ומכיוון שהם רוצים יותר אבטחה, הם ללא ספק ינסו להשתמש בו. בשלב מסוים הוא ייחסם, וכאשר משתמש חכם אחר (אולי מומחה הפצה) יכניס אותו לסקריפט init והמערכות יפסיקו לעבוד, המשתמשים יצטרכו להתלונן רק בפני לינוס טורוואלדס עצמו”.

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

"הקרנל לא אמור לערבב מקורות רעש שונים ביחד, והוא בהחלט לא צריך לנסות לטעון שהוא יודע כמה סיביות של אנטרופיה הוא מקבל כשהוא מנסה לשחק סוג של "משחק אנטרופיה מתפתל" על מעבד פשוט להחריד ארכיטקטורה למשתמשים צרכניים. IOT/Embedded מקרים שבהם הכל לא מסונכרן עם מתנד מאסטר יחיד, שבהם אין הוראת CPU לסדר מחדש או לשנות שם של אוגר וכו'.

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

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

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

כמה מודעות 🙂

תודה שנשארת איתנו. האם אתה אוהב את המאמרים שלנו? רוצים לראות עוד תוכן מעניין? תמכו בנו על ידי ביצוע הזמנה או המלצה לחברים, Cloud VPS למפתחים החל מ-$4.99, אנלוגי ייחודי של שרתים ברמת הכניסה, שהומצא על ידינו עבורכם: כל האמת על VPS (KVM) E5-2697 v3 (6 ליבות) 10GB DDR4 480GB SSD 1Gbps החל מ-$19 או איך לשתף שרת? (זמין עם RAID1 ו-RAID10, עד 24 ליבות ועד 40GB DDR4).

Dell R730xd זול פי 2 במרכז הנתונים Equinix Tier IV באמסטרדם? רק כאן 2 x Intel TetraDeca-Core Xeon 2x E5-2697v3 2.6GHz 14C 64GB DDR4 4x960GB SSD 1Gbps 100 TV החל מ-$199 בהולנד! Dell R420 - 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB - החל מ-$99! לקרוא על כיצד לבנות תשתיות קורפ. מחלקה עם שימוש בשרתי Dell R730xd E5-2650 v4 בשווי 9000 יורו עבור אגורה?

מקור: www.habr.com