הגדרה של הרשאה בהתאמה אישית לאפליקציה

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

רקע

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

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

חתימה על אפליקציות

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

הענקת הרשאות חתימה לאחר זמן הייצור של המכשיר

החל מ-Android 12 (רמת API 31), מאפיין knownCerts עבור הרשאות ברמת החתימה מאפשרות לעיין בתקצירים של חתימות ידועות אישורים בהצהרה בזמן האימון.

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

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

מזהי משתמשים וגישה לקבצים

בזמן ההתקנה, מערכת Android מעניקה לכל חבילה מזהה משתמש ייחודי של Linux. הזהות נשארת קבועה לכל משך חיי החבילה, במכשיר. במכשיר אחר, יכול להיות שלאותה חבילה יש UID – מה שחשוב הוא שלכל חבילה יש UID ייחודי במכשיר.

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

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

למידע נוסף על מודל האבטחה של Android, אפשר לעיין במאמר אבטחת Android סקירה כללית

הגדרה ואכיפה של הרשאות

כדי לאכוף את ההרשאות שלך, קודם צריך להצהיר עליהן AndroidManifest.xml באמצעות מאפיין אחד או יותר רכיבי <permission>.

המוסכמה למתן שמות

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

מומלץ להוסיף להרשאות את שם החבילה של אפליקציה, באמצעות מתן שמות בסגנון דומיין הפוך, ואחריו .permission. ואז תיאור של היכולת שההרשאה מייצגת, SNAKE_CASE למעלה. לדוגמה, com.example.myapp.permission.ENGAGE_HYPERSPACE

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

דוגמה

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

<manifest
  xmlns:android="http://schemas.android.com/apk/res/android"
  package="com.example.myapp" >
    
    <permission
      android:name="com.example.myapp.permission.DEADLY_ACTIVITY"
      android:label="@string/permlab_deadlyActivity"
      android:description="@string/permdesc_deadlyActivity"
      android:permissionGroup="android.permission-group.COST_MONEY"
      android:protectionLevel="dangerous" />
    ...
</manifest>

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

android:permissionGroup הוא אופציונלי ומשמש רק כדי לעזור למערכת להציג הרשאות למשתמש. ברוב המקרים, מגדירים את האפשרות הזו כמערכת סטנדרטית. קבוצה (רשומה ב-android.Manifest.permission_group), למרות שאתה יכול להגדיר קבוצה בעצמך, כפי שמתואר בחלק הבא. מומלץ להשתמש בקבוצה קיימת, כי זה מפשט ממשק המשתמש של ההרשאות שמוצג למשתמש.

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

דוגמה לתווית ולתיאור של CALL_PHONE הרשאה:

<string name="permlab_callPhone">directly call phone numbers</string>
<string name="permdesc_callPhone">Allows the app to call non-emergency
phone numbers without your intervention. Malicious apps may cause unexpected
calls on your phone bill.</string>

יצירה של קבוצת הרשאות

כמו שאפשר לראות בקטע הקודם, אפשר להשתמש android:permissionGroup כדי לעזור למערכת לתאר הרשאות למשתמש. ברוב המקרים, מגדירים קבוצת מערכות (רשומה ב- android.Manifest.permission_group), אבל אתם יכולים גם להגדיר קבוצה משלכם <permission-group>.

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

אפשר לתת הרשאה לקבוצה על ידי הקצאת שם הקבוצה ל- <permission> של אלמנט permissionGroup .

<permission-tree> הרכיב מצהיר על מרחב שמות לקבוצת הרשאות שמוגדרות

המלצות להרשאות בהתאמה אישית

אפשר להגדיר הרשאות מותאמות אישית לאפליקציות ולבקש הרשאות מותאמות אישית מאפליקציות אחרות על ידי הגדרת רכיבי <uses-permission>. עם זאת, חשוב לשקול היטב אם יש צורך לעשות זאת.

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

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