صندوق الرمل للتطبيقات في التطوير المحمول — ما هو، آلية عمله ومبدأ العمل

ما هو App Sandbox؟

صندوق الرمل للتطبيقات (App Sandbox) — هي آلية أمان معمارية تعزل كل تطبيق في بيئة تنفيذ خاصة به مع وصول محدود إلى موارد النظام. المصطلح مشتق من مفهوم «صندوق الرمل» للأطفال — مساحة آمنة حيث يمكن للطفل اللعب دون الوصول إلى أشياء خطرة. وبالمثل، يعمل التطبيق في بيئة مقيدة دون الوصول إلى بيانات التطبيقات الأخرى أو مكونات النظام الحرجة.

الهدف الرئيسي لـ Sandbox هو تنفيذ مبدأ أقل الامتيازات: يحصل كل تطبيق فقط على الحقوق اللازمة لأداء وظائفه المعلنة. حتى إذا وجد المهاجم ثغرة في تطبيق ما، فإن الصندوق الرملي يمنع الوصول إلى بيانات التطبيقات الأخرى أو الصور أو جهات الاتصال أو ملفات النظام. يقتصر الضرر على حدود تطبيق واحد.

طبقت أنظمة التشغيل المحمولة الصناديق الرملية قبل أنظمة سطح المكتب. iOS تستخدم Sandbox منذ إصدار أول SDK (2008)، Android منذ الإصدار 1.0 (2008)، مع تعزيز في Android 4.3 (2013) عبر SELinux. أنظمة سطح المكتب تلحق بالركب: macOS أدخلت Sandbox في 2012، Windows أدخل تطبيقات UWP المعزولة في Windows 8.

كيف يعمل العزل في الصندوق الرملي؟

يتم تحقيق العزل في الصندوق الرملي من خلال مجموعة من عدة آليات على مستويات مختلفة من نظام التشغيل. على مستوى نظام الملفات، يتم تخصيص دليل محمي خاص لكل تطبيق لا يملك الوصول الكامل إليه سواه. على مستوى العمليات، يتم استخدام معرف مستخدم فريد (UID) لكل تطبيق. على مستوى النواة، يتم تطبيق التحكم الإلزامي في الوصول (MAC) عبر SELinux أو آليات مماثلة.

عزل نظام الملفات

يحصل كل تطبيق على دليله الجذر الخاص على نظام ملفات الجهاز. في iOS، هذا هو الدليل /var/mobile/Containers/Data/Application/{UUID}، في Android — /data/data/{package_name}. يمكن للتطبيق قراءة وكتابة الملفات فقط داخل هذا الدليل. يتم حظر الوصول إلى أي ملفات خارج هذا الدليل على مستوى نواة نظام التشغيل.

يوفر النظام أيضًا أدلة مشتركة خاصة ذات وصول محدود. في iOS، هذه هي دليل Documents لبيانات المستخدم، Library للإعدادات و Caches للملفات المؤقتة. في Android — التخزين الداخلي (getFilesDir) والتخزين الخارجي (getExternalFilesDir)، التي لا يتطلب الوصول إليها أذونات إضافية.

عزل العمليات و UID

في Android، يتم تشغيل كل تطبيق كـ عملية Linux منفصلة مع UID فريد (معرف المستخدم). يتم تعيين UID عند تثبيت التطبيق ويبقى دون تغيير طوال دورة حياته. العمليات ذات UID المختلفة معزولة عن بعضها البعض على مستوى النواة — لا يمكنها الوصول إلى ذاكرة أو ملفات بعضها البعض. آلية مماثلة تعمل في iOS عبر نواة XNU ونظام الحماية الخاص بها.

طبقة حماية إضافية في Android يوفرها SELinux (Security-Enhanced Linux) في وضع enforcing منذ Android 4.3. ينفذ SELinux التحكم الإلزامي في الوصول (MAC): يتم التحقق من كل إجراء للعملية مقابل سياسة الأمان بغض النظر عن أذونات مالك الملف. حتى إذا كان التطبيق يعمل بصلاحية UID root، يمكن لـ SELinux حظر الوصول إلى موارد معينة.

صندوق الرمل في iOS

يعتبر صندوق الرمل لنظام iOS من أكثر الصناديق الرملية صرامة بين أنظمة التشغيل المحمولة. كل تطبيق معزول على مستوى الحاوية — منطقة محمية من نظام الملفات لا يمكن الوصول إليها من التطبيقات الأخرى. تستخدم iOS مزيجًا من التحكم الإلزامي في الوصول عبر Sandbox Kernel Extension (Sandbox.kext) وآلية entitlement لمنح الامتيازات الموسعة.

هيكل حاوية iOS

تتكون حاوية تطبيق iOS من عدة أدلة بمستويات وصول مختلفة. Documents — لبيانات المستخدم التي يتم حفظها عند النسخ الاحتياطي عبر iCloud و iTunes. Library — لملفات التكوين والذاكرة المؤقتة. tmp — للبيانات المؤقتة التي قد يحذفها النظام في أي وقت. AppName.app — حزمة التطبيق نفسها، وهي للقراءة فقط.

الوصول إلى بيانات التطبيقات الأخرى ممنوع منعًا باتًا. لا توفر iOS API لقراءة الملفات من حاوية تطبيق آخر. الطريقة الوحيدة لمشاركة البيانات هي من خلال آليات النظام: UIActivityViewController للمشاركة، UIPasteboard للحافظة، App Groups لتطبيقات نفس المطور. تعمل كل هذه الآليات تحت سيطرة نظام التشغيل.

Entitlements و App Sandbox في iOS

يتم توفير الإمكانيات الموسعة خارج الصندوق الرملي القياسي من خلال Entitlements — تواقيع رقمية تضاف إلى توقيع كود التطبيق. على سبيل المثال، entitlement com.apple.security.application-groups يسمح للتطبيقات من نفس المجموعة بمشاركة حاوية مشتركة. الإشعارات الفورية و iCloud و Apple Pay — كل هذه الوظائف تتطلب entitlements مقابلة.

من المهم ملاحظة أن entitlements في iOS ليست نفس الأذونات. الأذونات تُطلب من المستخدم في وقت التشغيل (مثل الوصول إلى الكاميرا)، بينما يتم التحقق من entitlements من قبل النظام في مرحلة التثبيت ولا يمكن للمستخدم تغييرها. يتم تعريف entitlements من قبل المطور ويتم توقيعها من قبل Apple أثناء عملية مراجعة التطبيق.

صندوق الرمل في Android

يستخدم Android نموذج صندوق رمل متعدد المستويات يعتمد على نواة Linux. يعمل كل تطبيق كـ مستخدم Linux منفصل بمعرف UID فريد، مما يوفر عزلًا أساسيًا على مستوى العمليات والملفات. تشمل المستويات الإضافية SELinux للتحكم الإلزامي في الوصول والأذونات للتحكم في الوصول إلى API النظام.

SELinux وعزل UID

SELinux في Android يعمل في وضع enforcing، مما يعني التطبيق الإجباري لسياسات الأمان. يتم تعيين سياق أمان لكل تطبيق، ويتم التحقق من جميع استدعاءات النظام مقابل السياسة. SELinux في Android يحتوي على أكثر من 1500 قاعدة تغطي نظام الملفات والتواصل بين العمليات والمقابس واستدعاءات النظام.

يمنع عزل UID الوصول المباشر لتطبيق إلى ملفات تطبيق آخر. على سبيل المثال، التطبيق A مع UID 10001 لا يمكنه قراءة ملفات التطبيق B مع UID 10002، حتى إذا كان كلاهما يعمل تحت حساب مستخدم الهاتف نفسه. هذا هو المبدأ الأساسي لأمان متعدد المستخدمين في Linux، المُكيَّف للأجهزة المحمولة.

// الوصول إلى الدليل الخاص بالتطبيق في Android
File appDir = context.getFilesDir();
File cacheDir = context.getCacheDir();
File externalDir = context.getExternalFilesDir(null);

// محاولة الوصول إلى دليل تطبيق آخر ستؤدي إلى SecurityException
// File otherApp = new File("/data/data/com.other.app/shared_prefs/");

// استخدام FileProvider للمشاركة الآمنة للملفات
Uri contentUri = FileProvider.getUriForFile(
    context, "com.example.fileprovider", file
);

يوفر Android آليات إضافية للتبادل الآمن للبيانات بين التطبيقات. ContentProvider — مكون Android يسمح للتطبيق بتوفير الوصول إلى بياناته للتطبيقات الأخرى عبر URI محدد بدقة. FileProvider — طريقة آمنة لمشاركة الملفات دون كشف مسارات نظام الملفات.

قيود وأمان الصندوق الرملي

على الرغم من أن App Sandbox هي آلية حماية قوية، إلا أن لديها قيودًا أساسية. يحمي الصندوق الرملي من الوصول الأفقي (من تطبيق إلى تطبيق)، ولكن ليس من الوصول الرأسي (برمجيات خبيثة على مستوى النواة أو وصول مادي للجهاز). مع الجيلبريك أو صلاحية root، يمكن تجاوز الصندوق الرملي حيث يحصل المهاجم على صلاحيات المستخدم المتميز.

القيد الثاني هو الأذونات الضارة. إذا منح المستخدم لتطبيق ما الوصول إلى جهات الاتصال والميكروفون، لا يمكن للصندوق الرملي منع جمع هذه البيانات لأن التطبيق يستخدم API نظام مشروعة. تنتقل الحماية في هذه الحالة إلى مستوى وعي المستخدم وعمليات مراجعة App Store و Google Play.

القيد الثالث هو التفاعل بين الصناديق الرملية. بعض خدمات النظام (NotificationListenerService, AccessibilityService) لديها وصول موسع إلى بيانات التطبيقات الأخرى. يمكن للمهاجم استخدام هذه الخدمات لتجاوز الصندوق الرملي إذا حصل على الأذونات المناسبة. تقوم Google و Apple بتحديث السياسات باستمرار لهذه الخدمات.

على الرغم من القيود، يعد الصندوق الرملي مكون أمان حاسم لأنظمة التشغيل المحمولة. وفقًا لـ Android Security Report (2024)، يمنع عزل الصندوق الرملي أكثر من 99% من محاولات الوصول بين التطبيقات. بالإضافة إلى Code Signing و App Review وأذونات وقت التشغيل، يشكل Sandbox حماية متعددة المستويات للجهاز المحمول الحديث.