موبائل ڈویلپمنٹ میں App Sandbox — یہ کیا ہے، طریقہ کار اور کام کا اصول

App Sandbox کیا ہے؟

App Sandbox — ایک آرکیٹیکچرل سیکیورٹی طریقہ کار ہے جو ہر ایپلیکیشن کو سسٹم کے وسائل تک محدود رسائی کے ساتھ اپنے عملدرآمد کے ماحول میں الگ کرتا ہے۔ یہ اصطلاح بچوں کے سینڈ باکس کے تصور سے آئی ہے — ایک محفوظ جگہ جہاں بچہ خطرناک اشیاء تک رسائی کے بغیر کھیل سکتا ہے۔ اسی طرح، ایک ایپلیکیشن دوسری ایپلیکیشنز کے ڈیٹا یا اہم سسٹم اجزاء تک رسائی کے بغیر محدود ماحول میں چلتی ہے۔

Sandbox کا بنیادی مقصد کم سے کم مراعات کے اصول کا نفاذ ہے: ہر ایپلیکیشن اپنے بیان کردہ افعال کو انجام دینے کے لیے صرف ضروری حقوق حاصل کرتی ہے۔ یہاں تک کہ اگر حملہ آور کسی ایپلیکیشن میں کمزوری ڈھونڈ لے، سینڈ باکس دوسری ایپلیکیشنز کے ڈیٹا، تصاویر، رابطوں یا سسٹم فائلوں تک رسائی کو روکتا ہے۔ نقصان ایک ایپلیکیشن کی حدود تک محدود رہتا ہے۔

موبائل آپریٹنگ سسٹمز نے ڈیسک ٹاپ سے پہلے سینڈ باکسز نافذ کیے۔ iOS پہلی SDK ریلیز (2008) سے Sandbox استعمال کر رہا ہے، Android ورژن 1.0 (2008) سے، Android 4.3 (2013) میں SELinux کے ذریعے مضبوطی کے ساتھ۔ ڈیسک ٹاپ سسٹمز پکڑ رہے ہیں: macOS نے 2012 میں Sandbox متعارف کرایا، Windows نے Windows 8 میں علیحدہ UWP ایپلیکیشنز متعارف کرائیں۔

سینڈ باکس میں علیحدگی کیسے کام کرتی ہے؟

سینڈ باکس میں علیحدگی آپریٹنگ سسٹم کی مختلف سطحوں پر کئی طریقہ کاروں کے امتزاج سے حاصل کی جاتی ہے۔ فائل سسٹم کی سطح پر، ہر ایپلیکیشن کو اپنی محفوظ ڈائریکٹری مختص کی جاتی ہے جس تک صرف اس کی مکمل رسائی ہوتی ہے۔ عمل کی سطح پر، ہر ایپلیکیشن کے لیے ایک منفرد صارف شناخت کنندہ (UID) استعمال کیا جاتا ہے۔ دانا (kernel) کی سطح پر، SELinux یا اسی طرح کے طریقہ کار کے ذریعے لازمی رسائی کنٹرول (MAC) کا اطلاق کیا جاتا ہے۔

فائل سسٹم کی علیحدگی

ہر ایپلیکیشن ڈیوائس کے فائل سسٹم پر اپنی روٹ ڈائریکٹری حاصل کرتی ہے۔ iOS میں، یہ ڈائریکٹری /var/mobile/Containers/Data/Application/{UUID} ہے، Android میں — /data/data/{package_name}۔ ایپلیکیشن صرف اس ڈائریکٹری کے اندر فائلیں پڑھ اور لکھ سکتی ہے۔ اس ڈائریکٹری سے باہر کسی بھی فائل تک رسائی آپریٹنگ سسٹم کے دانا (kernel) کی سطح پر مسدود کر دی جاتی ہے۔

سسٹم محدود رسائی کے ساتھ خاص مشترکہ ڈائریکٹریاں بھی فراہم کرتا ہے۔ iOS میں، یہ صارف کے ڈیٹا کے لیے Documents ڈائریکٹری، ترتیبات کے لیے Library اور عارضی فائلوں کے لیے Caches ہیں۔ Android میں — اندرونی ذخیرہ (getFilesDir) اور بیرونی ذخیرہ (getExternalFilesDir)، جن تک رسائی کے لیے اضافی اجازتوں کی ضرورت نہیں ہوتی۔

عمل اور UID کی علیحدگی

Android میں، ہر ایپلیکیشن ایک منفرد UID (صارف ID) کے ساتھ ایک علیحدہ Linux عمل کے طور پر چلتی ہے۔ UID ایپلیکیشن انسٹال کرتے وقت مقرر کیا جاتا ہے اور اپنی پوری زندگی میں تبدیل نہیں ہوتا۔ مختلف UIDs والے عمل دانا (kernel) کی سطح پر ایک دوسرے سے الگ تھلگ ہوتے ہیں — وہ ایک دوسرے کی میموری یا فائلوں تک رسائی حاصل نہیں کر سکتے۔ iOS میں XNU دانا اور اس کے حفاظتی نظام کے ذریعے اسی طرح کا طریقہ کار کام کرتا ہے۔

Android میں تحفظ کی ایک اضافی تہہ SELinux (Security-Enhanced Linux) کے ذریعے Android 4.3 سے enforcing موڈ میں فراہم کی جاتی ہے۔ 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۔ یہ تمام طریقہ کار آپریٹنگ سسٹم کے کنٹرول میں کام کرتے ہیں۔

iOS میں Entitlements اور App Sandbox

معیاری سینڈ باکس سے آگے توسیعی صلاحیتیں Entitlements کے ذریعے فراہم کی جاتی ہیں — ڈیجیٹل دستخط جو ایپلیکیشن کے کوڈ دستخط میں شامل کیے جاتے ہیں۔ مثال کے طور پر، entitlement com.apple.security.application-groups ایک ہی گروپ کی ایپلیکیشنز کو مشترکہ کنٹینر رکھنے کی اجازت دیتا ہے۔ پش اطلاعات، iCloud، Apple Pay — ان تمام خصوصیات کے لیے متعلقہ entitlements کی ضرورت ہوتی ہے۔

یہ نوٹ کرنا ضروری ہے کہ iOS میں entitlements اجازتوں جیسی نہیں ہیں۔ اجازتیں رن ٹائم پر صارف سے درخواست کی جاتی ہیں (مثلاً، کیمرے تک رسائی)، جبکہ entitlements کو انسٹالیشن کے وقت سسٹم کے ذریعے چیک کیا جاتا ہے اور صارف انہیں تبدیل نہیں کر سکتا۔ Entitlements ڈویلپر کے ذریعے متعین کیے جاتے ہیں اور ایپ ریویو کے عمل کے دوران Apple کے ذریعے دستخط کیے جاتے ہیں۔

Android میں سینڈ باکس

Android Linux دانا پر مبنی ایک کثیر سطحی سینڈ باکس ماڈل استعمال کرتا ہے۔ ہر ایپلیکیشن ایک منفرد UID کے ساتھ ایک علیحدہ Linux صارف کے طور پر چلتی ہے، جو عمل اور فائل کی سطح پر بنیادی علیحدگی فراہم کرتی ہے۔ اضافی سطحوں میں لازمی رسائی کنٹرول کے لیے SELinux اور سسٹم API تک رسائی کو کنٹرول کرنے کے لیے اجازتیں شامل ہیں۔

SELinux اور UID علیحدگی

Android میں SELinux enforcing موڈ میں چلتا ہے، جس کا مطلب ہے سیکیورٹی پالیسیوں کا لازمی نفاذ۔ ہر ایپلیکیشن کو سیکیورٹی سیاق و سباق (security context) تفویض کیا جاتا ہے، اور تمام سسٹم کالز پالیسی کے خلاف چیک کی جاتی ہیں۔ SELinux Android میں 1500 سے زیادہ قواعد پر مشتمل ہے جو فائل سسٹم، بین العمل مواصلات، ساکٹ اور سسٹم کالز کا احاطہ کرتا ہے۔

UID علیحدگی ایک ایپلیکیشن کو دوسری ایپلیکیشن کی فائلوں تک براہ راست رسائی سے روکتی ہے۔ مثال کے طور پر، UID 10001 والی ایپلیکیشن A، UID 10002 والی ایپلیکیشن B کی فائلیں نہیں پڑھ سکتی، چاہے دونوں ایک ہی فون صارف اکاؤنٹ کے تحت چل رہی ہوں۔ یہ 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% سے زیادہ کوششوں کو روکتی ہے۔ کوڈ سائننگ، ایپ ریویو اور رن ٹائم اجازتوں کے ساتھ مل کر، Sandbox جدید موبائل ڈیوائس کی کثیر سطحی حفاظت تشکیل دیتا ہے۔