גוגל מחויבת לקדם הון גזעי עבור קהילות שחורות. תראה איך.
דף זה תורגם על ידי Cloud Translation API.
Switch to English

הספק איניט

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

ספק init נועד לסגור את החור הזה באמצעות תחום לינוקס (SELinux) משופר לאבטחה (SELinux) vendor_init להפעלת פקודות שנמצאות /vendor עם הרשאות ספציפיות לספק.

מַנגָנוֹן

הספק init שולח תהליך משנה של init בשלב מוקדם של אתחול עם הקשר SELinux u:r:vendor_init:s0 . להקשר זה של SELinux יש הרבה פחות הרשאות מהקשר של ברירת המחדל של ה- init והגישה שלו מוגבלת לקבצים, נכסים וכו 'שהם ספציפיים לספקים או שהם חלק ממוצר יצרני המערכת ABI.

Init בודק כל סקריפט שהוא טוען כדי לראות אם הנתיב שלו מתחיל ב- /vendor ואם כן, מתייג אותו בסימן שצריך להפעיל את הפקודות שלו בהקשר של הספק. כל מובנה init מסומן ב בוליאני שמציין אם הפקודה חייבת להיות מופעלת בתהליך משנה של הספק init:

  • מרבית הפקודות הניגשות למערכת הקבצים מצוינות בהפעלה בתת-עיבוד הספק init ולכן הן כפופות לספק init SEPolicy.
  • מרבית הפקודות המשפיעות על מצב הכניסה הפנימי (למשל שירותי התחלה והפסקה) מופעלות בתהליך ה- Init הרגיל. פקודות אלה מודעות לכך שסקריפט של ספק קורא להם לבצע את הרשאותיהם שאינן SELinux.

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

באמצעות ספק Init

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

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

type=1400 audit(1511821362.996:9): avc: denied { search } for pid=540 comm="init" name="nfc" dev="sda45" ino=1310721 scontext=u:r:vendor_init:s0 tcontext=u:object_r:nfc_data_file:s0 tclass=dir permissive=0
init: Command 'write /data/nfc/bad_file_access 1234' action=boot (/vendor/etc/init/hw/init.walleye.rc:422) took 2ms and failed: Unable to write to file '/data/nfc/bad_file_access': open() failed: Permission denied

אם פקודה נכשלה, ישנן שתי אפשרויות:

  • אם הפקודה נכשלה בגלל מגבלה מיועדת (למשל אם הפקודה ניגשת לקובץ מערכת או נכס), יש ליישם מחדש את הפקודה בדרך ידידותית לטרבל, לעבור רק ממשקים יציבים. כללים שלילית אינם מונעים הוספת הרשאות לגישה לקבצי מערכת שאינם חלק מספקיות המערכת היציבה ABI.
  • אם תווית SELinux היא חדשה וכבר לא ניתנות לה הרשאות ב- vendor_init.te המערכת ואף לא vendor_init.te הרשאות באמצעות הכללים המותרים לעולם, יתכן ותוענק לתווית החדשה הרשאות ב vendor_init.te הספציפי vendor_init.te .

עבור מכשירים המשיקים לפני אנדרואיד 9, ניתן לעקוף את data_between_core_and_vendor_violators ה- data_between_core_and_vendor_violators שלא על ידי הוספת קובץ vendor_init.te לקובץ vendor_init.te הספציפי vendor_init.te .

מיקומי קוד

עיקר ההיגיון עבור ספק ה- IPC של הספק הוא במערכת / core / init / subcontext.cpp .

טבלת הפקודות נמצאת בכיתת BuiltinFunctionMap במערכת / core / init / buildins.cpp וכוללת הערות המציינות אם הפקודה חייבת לפעול בתת-מעבד הספק init.

SEPolicy עבור init הספק מפוצל בין ספריות הפרטיות ( system / sepolicy / private / vendor_init.te ) והציבוריות ( system / sepolicy / public / vendor_init.te ) במערכת / sepolicy.