تحديد إذن مخصَّص للتطبيق

ويوضّح هذا المستند كيف يمكن لمطوّري التطبيقات استخدام ميزات الأمان التي يوفّرها Android لتحديد أذوناتهم الخاصة. ومن خلال تحديد أذونات مخصّصة، يمكن للتطبيق مشاركة موارده وإمكاناته مع تطبيقات أخرى. لمزيد من المعلومات حول الأذونات، يُرجى الاطّلاع على نظرة عامة على الأذونات.

خلفية

Android هو نظام تشغيل منفصل عن الامتيازات، حيث يعمل كل تطبيق بهوية نظام خاصة (رقم تعريف مستخدم Linux ومعرّف المجموعة). وتُفصل أجزاء النظام أيضًا في هويات مختلفة. وبالتالي، يعزل Linux التطبيقات عن بعضها البعض وعن النظام.

يمكن للتطبيقات عرض وظائفها للتطبيقات الأخرى من خلال تحديد الأذونات التي يمكن للتطبيقات الأخرى طلبها. ويمكنهم أيضًا تحديد الأذونات التي يتم توفيرها تلقائيًا لأي تطبيقات أخرى موقّعة باستخدام الشهادة نفسها.

توقيع التطبيق

يجب توقيع جميع حِزم APK باستخدام شهادة يحتفظ المطوّر بمفتاحها الخاص. لا تحتاج الشهادة إلى توقيع من مرجع تصديق. من المقبول عادةً أن تستخدم تطبيقات Android الشهادات الموقَّعة ذاتيًا. والغرض من الشهادات في Android هو التفريق بين مطوّري التطبيقات. يتيح هذا الأمر للنظام منح التطبيقات إمكانية الوصول إلى أذونات على مستوى التوقيع أو رفضها، بالإضافة إلى منح أو رفض طلب منح التطبيق نفس هوية Linux لتطبيق آخر أو رفضه.

منح أذونات التوقيع بعد مرور وقت تصنيع الجهاز

بدءًا من نظام التشغيل Android 12 (المستوى 31 لواجهة برمجة التطبيقات)، تتيح لك السمة knownCerts الخاصة بالأذونات على مستوى التوقيع الاطّلاع على ملخصات شهادات التوقيع المعروفة في وقت البيان.

يمكنك الإفصاح عن السمة knownCerts واستخدام العلامة knownSigner في سمة protectionLevel الخاصة بتطبيقك للحصول على إذن معيّن على مستوى التوقيع. بعد ذلك، يمنح النظام ذلك الإذن للتطبيق الذي يطلب الإذن في حال تطابق أي موقِّع ضمن سجلّ توقيع التطبيق الذي يقدّم الطلب، بما في ذلك الموقِّع الحالي، مع أحد الملخّصات التي تم توضيحها باستخدام الإذن في السمة knownCerts.

تسمح العلامة knownSigner للأجهزة والتطبيقات بمنح أذونات التوقيع للتطبيقات الأخرى بدون الحاجة إلى توقيع التطبيقات في وقت تصنيع الجهاز وشحنه.

أرقام تعريف المستخدمين والوصول إلى الملفات

أثناء التثبيت، يمنح نظام التشغيل Android كل حزمة رقم تعريف مستخدم مميز لنظام التشغيل Linux. وتظل الهوية ثابتة طوال مدة عمر الطرد على ذلك الجهاز. وعلى جهاز مختلف، قد يكون للحزمة نفسها معرّف فريد مختلف، ولكن المهم هو أنّ كل حزمة لها معرّف فريد مختلف على جهاز معيّن.

وبما أنّ فرض الأمان يتم على مستوى العملية، لا يمكن عادةً تشغيل رمز أي حزمتَين في العملية نفسها، لأنّه يجب تشغيلهما كمستخدمين مختلفين لنظام التشغيل 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>. ومع ذلك، عليك تقييم ضرورة إجراء ذلك بعناية.

  • إذا كنت تصمّم مجموعة من التطبيقات التي تعرض وظائف لبعضها البعض، حاوِل تصميم التطبيقات بحيث يتم تحديد كل إذن مرة واحدة فقط. ويجب إجراء ذلك إذا لم تكن جميع التطبيقات موقَّعة باستخدام الشهادة نفسها. وحتى إذا تم توقيع جميع التطبيقات باستخدام الشهادة نفسها، من أفضل الممارسات تحديد كل إذن مرة واحدة فقط.
  • إذا كانت الوظيفة متوفرة فقط للتطبيقات الموقَّعة بالتوقيع نفسه المُستخدَم في التطبيق المقدّم، قد تتمكن من تجنُّب تحديد أذونات مخصَّصة باستخدام عمليات التحقّق من التوقيعات. وعندما يطلب أحد تطبيقاتك استخدام تطبيق آخر، يمكن للتطبيق الثاني التحقّق من توقيع التطبيقَين باستخدام الشهادة نفسها قبل الالتزام بالطلب.

إذا كان الحصول على إذن مخصّص ضروريًا، فكِّر في ما إذا كانت التطبيقات التي وقّع عليها مطوّر التطبيق نفسه والتي تُجري فحص الأذونات تتطلب الوصول إليه فقط، مثلاً عند تنفيذ اتصالات آمنة بين العمليات بين تطبيقَين من مطوّر البرامج نفسه. إذا كان الأمر كذلك، ننصحك باستخدام أذونات التوقيع. تتسم أذونات التوقيع بالشفافية للمستخدم وتتجنّب الأذونات التي أكدها المستخدم، ما قد يؤدي إلى إرباك المستخدمين.

متابعة القراءة حول:

<uses-permission>
مرجع واجهة برمجة التطبيقات لعلامة البيان الذي يوضِّح أذونات النظام المطلوبة لتطبيقك.

قد يهمك أيضًا الاطّلاع على ما يلي:

نظرة عامة على الأمان في Android
مناقشة تفصيلية حول نموذج الأمان لنظام Android الأساسي