מדריך לשילוב של בקר להגבלות על ניפוי באגים

צריך להשתמש בהוראות שבדף הזה כדי לשלב את AAOS Debugging Restriction Controller (הרפובליקה הדמוקרטית של קונגו).

איור 1. דוגמה לאפליקציה של DRC.

ארכיטקטורה

הארכיטקטורה של ה-DRC מתוארת באיור 2. הרכיבים מסומנים באדום (מנפיק האסימון DRC) יש הטמעות של קובצי עזר נלוות שניתן להתאים אישית.

איור 2. הארכיטקטורה של הרפובליקה הדמוקרטית של קונגו.

מהי ה-DRC?

היחידה הראשית (HU) של הרכב כוללת את אפליקציית DRC (ניתן לעיין ביישום ההפניה ב packages/apps/Car/DebuggingRestrictionController). אפליקציית העזר כוללת הלוגיקה של קבלת אסימון גישה ממנפיק האסימון, אימות האסימון, ואז להחיל שינויים בהגבלה על ניפוי באגים כפי שצוין באסימון. הלוגיקה כוללת רכיבים בסיסיים של חוויית המשתמש בצד הרכב.

מי מנפיק האסימון?

זהו שירות אינטרנט שמנפיק אסימוני גישה חתומים באופן קריפטוגרפי (אפשר לעיין בחומר העזר ב-packages/apps/Car/DebuggingRestrictionController/server). שירות האינטרנט לדוגמה הוא פונקציית Firebase Cloud שאפשר לפרוס (מידע נוסף זמין במאמר הבא: Cloud Functions עבור Firebase).

דרישות מוקדמות

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

הכנת אישורים לחתימה על אסימוני גישה

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

האישור של ישות הקצה החותם על אסימוני ה-JWS לא שונה מ-TLS סטנדרטי. אישור. אפשר לרכוש אישור מרשויות אישורים ציבוריות כמו DigiCert או לתחזק שרשרת אישורים משלכם באמצעות אישורי CA בסיסיים בחתימה עצמית או מודולי אבטחה של חומרה. האישור של ישות הקצה צריך להיות אישור X509v3 עם שם חלופי לנושא (SAN). תוסף SAN מכיל מזהה (למשל, שם מארח) של האסימון של מנפיק הכרטיס. לסיום, צריך לתת עדיפות לאישורי RSA על פני אישורי EC כי האסימון המנפיק תומך רק ב-RS256.

Google מספקת סקריפט מעטפת ליצירת אישורים עם חתימה עצמית packages/apps/Car/DebuggingRestrictionController/server/genkey.sh

מגדירים את Firebase

המנפיק של אסימון ההפניה משתמש אימות ב-Firebase וגם הפונקציה של Firebase Cloud Functions.

כדי להגדיר את החשבון ב-Firebase:

1. כדי ליצור פרויקט Firebase: הוספת Firebase אל לפרויקט Android שלכם.
2. כדי להפעיל חלק ממאמתי Firebase: איפה אפשר למצוא להתחיל באימות ב-Firebase?
3. כדי להוסיף פונקציה ריקה של Firebase Cloud: הרשמה התחיל.
4. אם עדיין לא סיימתם, מתקינים את הכלים Node.js, NPM ו-Firebase כדי להדר לפרוס את מנפיק האסימון.
   הערה: אחרי שיוצרים פרויקט Firebase, תוצג בקשה כדי להוריד קובץ תצורה בשם google-services.json. הקובץ לא מכיל מידע רגיש, שנעשה בו שימוש גם על ידי אפליקציית ההפניה של ה-DRC וגם על ידי מנפיק האסימון מאוחר יותר.

משלבים את האפליקציה DRC

אפליקציית ההפניה של DRC ממוקמת ב packages/apps/Car/DebuggingRestrictionController ניתן ליצור את האפליקציה נכלל בחבילה ב-AOSP עם Soong או unbundled עם Gradle.

גרסת build שכלולה בחבילה

כדי לבנות אפליקציה בחבילה:

1. להעתיק את applicationId, projectId וapiKey מgoogle-services.json אל packages/apps/Car/DebuggingRestrictionController/soong/FirebaseApplication.java כך אפשר לחבר את האפליקציה של ה-DRC ל-Firebase בצורה נכונה.
2. מעדכנים את הקבועים האלה ב- packages/apps/Car/DebuggingRestrictionController/soong/BuildConfig.java:
   • TOKEN_USES_SELF_SIGNED_CA מציין אם אישורי CA בסיסיים בחתימה עצמית בשימוש. אם המדיניות מופעלת, האפליקציה DRC נותנת אמון רק באישור ה-CA הבסיסי בקידוד PEM שצוין ב- ROOT_CA_CERT
   • TOKEN_ISSUER_API_NAME הוא השם של הפונקציה ב-Firebase Cloud, והוא צריך תואמת לפונקציה של Cloud שיצרתם קודם במסוף Firebase.
   • TOKEN_ISSUER_HOSTNAME צריך להתאים לשם החלופי לנושא אישור של ישות הקצה לחתימה על אסימוני הגישה.
   • DRC_TEST_EMAIL ו-DRC_TEST_PASSWORD הם פרטי כניסה של חשבון בדיקה אופציונלי, שאפשר להקצות מראש ב-Firebase אם מפעילים כניסה לחשבון באמצעות אימייל או סיסמה. המדדים האלה משמשים לבדיקות אינסטרומנטליות בלבד.

זהו! האפליקציה מוגדרת לשימוש בחשבון Firebase ובאישורים שלך. ב-Android 9 ואילך, עליך להגדיר הוספה לרשימת ההיתרים של הרשאות בעלות הרשאות רשימת ההיתרים חייבת להכיל לפחות android.permission.MANAGE_USERS. לדוגמה:

<permissions>
  <privapp-permissions package="com.android.car.debuggingrestrictioncontroller">
    <permission name="android.permission.INTERNET"/>
    <permission name="android.permission.MANAGE_USERS"/>
  </privapp-permissions>
</permissions>

build לא בחבילה

גרסאות build של DRC לא משולבות משתמשות ב-Gradle כדי להדר את האפליקציה.

כדי ליצור build לא בחבילה:

1. מוודאים שהתקנתם את Android SDK.
2. יוצרים קובץ טקסט בשם local.properties בתיקיית השורש של האפליקציה.
3. הגדרת המיקום של Android SDK:

    sdk.dir=path/to/android/sdk
   

4. כדי להגדיר את Firebase, צריך להעתיק את google-services.json אל packages/apps/Car/DebuggingRestrictionController/app. Gradle מנתחת את הקובץ ומגדיר את השאר באופן אוטומטי.
5. להגדיר את משתני הסביבה. בדומה לגרסאות build בחבילה, צריך לציין:
   • $TOKEN_USES_SELF_SIGNED_CA: true או false;
   • $ROOT_CA_CERT: נתיב לאישור ה-CA ברמה הבסיסית בקידוד PEM.
   • $TOKEN_ISSUER_API_NAME: השם של הפונקציה של Firebase Cloud;
   • $TOKEN_ISSUER_HOST_NAME: SAN באישור;
   • $DRC_TEST_EMAIL ו-$DRC_TEST_EMAIL: פרטי כניסה לבדיקה חשבונות, גרסאות build לניפוי באגים בלבד.
6. כדי לפתח את האפליקציה באמצעות Gradle, מריצים פקודה כזו:

   $ ./gradlew build
   

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

משלבים את מנפיק האסימון

המנפיק של אסימון ההפניה הוא פונקציה של Cloud Functions של Firebase שמוטמעת ב-Node.js. רק משתמש מאומת יכול לקרוא לפונקציה. לפני פריסת האפליקציה, צריך להגדיר את המפתח הפרטי והאישורים שמשמשים לחתימה על אסימוני ה-JWS.

1. מאכלסים קובץ JSON עם התוכן הבא:

   {
       "key": "---BEGIN PRIVATE KEY---\nRSA_PRIVATE_KEY\n-----END PRIVATE KEY-----\n",
       "certificates.0": "-----BEGIN CERTIFICATE-----\nTOKEN_SIGNING_CERT\n-----END CERTIFICATE-----\n",
       "certificates.1": "-----BEGIN CERTIFICATE-----\nINTERMEDIATE_CA_CERT\n-----END CERTIFICATE-----\n",
       "certificates.2": "-----BEGIN CERTIFICATE-----\nROOT_CA_CERT\n-----END CERTIFICATE-----\n",
       "expiration": "30m",
       "issuer": "Debugging Access Token Issuer",
       "audience": "IHU"
   }
   

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

2. מעלים את ההגדרות האישיות ל-Firebase:

$ firebase functions:config:set api_config="$(cat YOUR_CONFIG.json)"

3. פורסים את הפונקציה של Firebase Cloud:

$ firebase deploy --only functions

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

הגדרה של הגבלות ברירת מחדל

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

אפשר להגדיר את הגבלת ברירת המחדל עבור משתמש במערכת ללא GUI באמצעות מערך המחרוזת config_defaultFirstUserRestrictions ב- frameworks/base/core/res/res/values/config.xml הגדרת ההגבלה הזו משבית באופן אוטומטי את ממשק Android Debug Bridge (ADB) עד להסרת ההגבלה, עבור דוגמה:

<string-array translatable="false" name="config_defaultFirstUserRestrictions">
  <item>no_debugging_features</item>
</string-array>

הגבלות ברירת המחדל שחלות על משתמשים רגילים (לדוגמה, נהגים ונוסעים), ואורחים יכולים להיות מוגדרים frameworks/base/core/res/res/xml/config_user_types.xml. אפשר ליצור שכבת-על מחרוזות כדי להגדיר את הגבלות ברירת המחדל על כל סוג של משתמש בהתאמה, לדוגמה:

<user-types>
  <full-type name="android.os.usertype.full.SECONDARY" >
    <default-restrictions no_debugging_features="true"/>
  </full-type>
  <full-type name="android.os.usertype.full.GUEST" >
    <default-restrictions no_debugging_features="true"/>
  </full-type>
</user-types>

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