Sandbox ng Aplikasyon sa mobile development — ano ito, mekanismo at prinsipyo ng paggana

Ano ang App Sandbox?

Sandbox ng Aplikasyon (App Sandbox) — mekanismo ng seguridad sa arkitektura na nag-iisolate ng bawat aplikasyon sa sarili nitong execution environment na may limitadong access sa system resources. Ang termino ay nagmula sa konsepto ng “sandbox” para sa mga bata — isang ligtas na espasyo kung saan ang bata ay maaaring maglaro nang walang access sa mga mapanganib na bagay. Sa pagkakatulad, ang aplikasyon ay gumagana sa limitadong kapaligiran, walang access sa data ng iba pang aplikasyon o kritikal na system components.

Ang pangunahing layunin ng Sandbox ay ang pagpapatupad ng prinsipyo ng minimal na mga pribilehiyo: bawat aplikasyon ay tumatanggap lamang ng mga karapatan na kinakailangan para sa pagganap ng mga deklaradong function. Kahit na makahanap ang attacker ng vulnerability sa aplikasyon, hindi pinapayagan ng sandbox na ma-access nito ang data ng iba pang aplikasyon, larawan, contact, o system file. Ang pinsala ay limitado sa saklaw ng isang aplikasyon.

Ang mga mobile operating system ay nagpatupad ng sandbox nang mas maaga kaysa sa desktop. iOS ay gumagamit ng Sandbox mula noong paglabas ng unang bersyon ng SDK (2008), Android — mula noong bersyon 1.0 (2008), ngunit may pagpapalakas sa Android 4.3 (2013) sa pamamagitan ng SELinux. Ang mga desktop system ay humahabol: macOS ay nagpatupad ng Sandbox noong 2012, Windows — mga isolated na UWP application sa Windows 8.

Paano gumagana ang isolation sa sandbox?

Ang isolation sa sandbox ay nakakamit sa pamamagitan ng kombinasyon ng ilang mekanismo sa iba't ibang antas ng operating system. Sa antas ng file system, bawat aplikasyon ay binibigyan ng sariling protektadong direktoryo kung saan ito lamang ang may ganap na access. Sa antas ng proseso, ginagamit ang natatanging user identifier (UID) para sa bawat aplikasyon. Sa antas ng kernel, inilalapat ang mandatory access control (MAC) sa pamamagitan ng SELinux o katulad na mekanismo.

Isolation ng file system

Bawat aplikasyon ay tumatanggap ng sariling root directory sa file system ng device. Sa iOS ito ang direktoryo na /var/mobile/Containers/Data/Application/{UUID}, sa Android — /data/data/{package_name}. Ang aplikasyon ay maaari lamang magbasa at magsulat ng mga file sa loob ng direktoryong ito. Ang access sa anumang file sa labas ng direktoryong ito ay naka-block sa antas ng kernel ng operating system.

Ang system ay nagbibigay din ng mga espesyal na shared directory na may limitadong access. Sa iOS ito ang Documents directory para sa data ng user, Library para sa mga setting, at Caches para sa pansamantalang file. Sa Android — internal storage (getFilesDir) at external storage (getExternalFilesDir), na ang access ay hindi nangangailangan ng karagdagang pahintulot.

Isolation ng proseso at UID

Sa Android, bawat aplikasyon ay pinapatakbo bilang hiwalay na Linux process na may natatanging UID (User ID). Ang UID ay itinatalaga sa pag-install ng aplikasyon at nananatiling hindi nagbabago sa buong lifecycle. Ang mga proseso na may iba't ibang UID ay isolated sa isa't isa sa antas ng kernel — hindi sila maaaring mag-access ng memory o file ng isa't isa. Ang katulad na mekanismo ay gumagana sa iOS sa pamamagitan ng XNU kernel at ng protection system nito.

Ang karagdagang antas ng proteksyon sa Android ay ibinibigay ng SELinux (Security-Enhanced Linux) sa enforcing mode mula noong Android 4.3. Ang SELinux ay nagpapatupad ng mandatory access control (MAC): bawat aksyon ng proseso ay sinusuri para sa pagsunod sa security policy anuman ang rights ng may-ari ng file. Kahit na ang aplikasyon ay tumatakbo na may root UID, maaaring i-block ng SELinux ang access sa partikular na resources.

Sandbox sa iOS

Ang iOS sandbox ay itinuturing na isa sa pinakamahigpit sa mga mobile operating system. Bawat aplikasyon ay isolated sa antas ng container — isang protektadong lugar ng file system na hindi ma-access mula sa iba pang aplikasyon. Gumagamit ang iOS ng kombinasyon ng mandatory access control sa pamamagitan ng Sandbox Kernel Extension (Sandbox.kext) at entitlement mechanism para sa pagbibigay ng pinalawak na mga karapatan.

Istruktura ng iOS container

Ang container ng iOS application ay binubuo ng ilang direktoryo na may iba't ibang antas ng access. Documents — para sa data ng user na nai-save sa backup sa pamamagitan ng iCloud at iTunes. Library — para sa configuration file at cache. tmp — para sa pansamantalang data na maaaring tanggalin ng system anumang oras. AppName.app — ang bundle ng aplikasyon mismo, na read-only.

Ang access sa data ng iba pang aplikasyon ay mahigpit na ipinagbabawal. Ang iOS ay hindi nagbibigay ng API para sa pagbabasa ng file mula sa container ng ibang aplikasyon. Ang tanging paraan ng pagpapalitan ng data ay sa pamamagitan ng system mechanisms: UIActivityViewController para sa pagbabahagi, UIPasteboard para sa clipboard, App Groups para sa mga aplikasyon ng iisang developer. Bawat isa sa mga mekanismong ito ay gumagana sa ilalim ng kontrol ng operating system.

Entitlements at App Sandbox sa iOS

Ang pinalawak na kakayahan sa labas ng standard na sandbox ay ibinibigay sa pamamagitan ng Entitlements — digital signatures na idinaragdag sa code signature ng aplikasyon. Halimbawa, ang entitlement na com.apple.security.application-groups ay nagpapahintulot sa mga aplikasyon mula sa isang grupo na magkaroon ng shared container. Ang Push notification, iCloud, Apple Pay — lahat ng mga feature na ito ay nangangailangan ng kaukulang entitlements.

Mahalagang tandaan na ang entitlements sa iOS ay hindi katulad ng mga pahintulot (permissions). Ang mga pahintulot ay hinihiling mula sa user sa runtime (halimbawa, access sa camera), samantalang ang entitlements ay sinusuri ng system sa yugto ng pag-install at hindi mababago ng user. Ang entitlement ay tinutukoy ng developer at pinipirmahan ng Apple sa proseso ng pag-review ng aplikasyon.

Sandbox sa Android

Ang Android ay gumagamit ng multi-layered na sandbox model na nakabatay sa Linux kernel. Bawat aplikasyon ay gumagana bilang hiwalay na Linux user na may natatanging UID, na nagbibigay ng pangunahing isolation sa antas ng proseso at file. Mga karagdagang layer — SELinux para sa mandatory access control at Permissions para sa kontrol ng access sa system API.

SELinux at UID isolation

Ang SELinux sa Android ay gumagana sa enforcing mode, na nangangahulugang sapilitang pagpapatupad ng security policies. Bawat aplikasyon ay binibigyan ng security context, at lahat ng system call ay sinusuri para sa pagsunod sa policy. Ang SELinux sa Android ay naglalaman ng higit sa 1500 rules na sumasaklaw sa file system, interprocess communication, socket, at system call.

Ang UID isolation ay pumipigil sa direktang access ng aplikasyon sa mga file ng ibang aplikasyon. Halimbawa, ang aplikasyon A na may UID 10001 ay hindi maaaring magbasa ng mga file ng aplikasyon B na may UID 10002, kahit na pareho silang tumatakbo sa ngalan ng iisang user ng telepono. Ito ang pangunahing prinsipyo ng multi-user security ng Linux na iniakma para sa mga mobile device.

// Access sa sariling direktoryo ng aplikasyon sa Android
File appDir = context.getFilesDir();
File cacheDir = context.getCacheDir();
File externalDir = context.getExternalFilesDir(null);

// Ang pagtatangkang mag-access sa direktoryo ng iba ay magdudulot ng SecurityException
// File otherApp = new File("/data/data/com.other.app/shared_prefs/");

// Paggamit ng FileProvider para sa ligtas na pagbabahagi ng file
Uri contentUri = FileProvider.getUriForFile(
    context, "com.example.fileprovider", file
);

Ang Android ay nagbibigay ng karagdagang mekanismo para sa ligtas na pagpapalitan ng data sa pagitan ng mga aplikasyon. ContentProvider — isang Android component na nagpapahintulot sa aplikasyon na magbigay ng access sa data nito sa iba pang aplikasyon sa pamamagitan ng mahigpit na tinukoy na URI. FileProvider — isang ligtas na paraan ng pagbabahagi ng file nang hindi inilalantad ang mga path ng file system.

Mga limitasyon at seguridad ng sandbox

Kahit na ang App Sandbox ay isang malakas na mekanismo ng proteksyon, mayroon itong pangunahing mga limitasyon. Ang sandbox ay nagpoprotekta laban sa horizontal access (application-to-application), ngunit hindi laban sa vertical access (malware sa antas ng kernel o physical access sa device). Sa jailbreak o root access, ang sandbox ay maaaring lampasan dahil ang attacker ay nakakakuha ng superuser rights.

Ang pangalawang limitasyon — mapanganib na mga pahintulot. Kung ang user ay nagbibigay sa aplikasyon ng access sa contact at mikropono, hindi mapipigilan ng sandbox ang pagkolekta ng data na ito dahil ang aplikasyon ay gumagamit ng lehitimong system API. Ang proteksyon sa kasong ito ay lumilipat sa antas ng kamalayan ng user at pag-review ng App Store at Google Play.

Ang pangatlong limitasyon — interaksyon sa pagitan ng mga sandbox. Ang ilang system services (NotificationListenerService, AccessibilityService) ay may pinalawak na access sa data ng iba pang aplikasyon. Ang attacker ay maaaring gumamit ng mga serbisyong ito para lampasan ang sandbox kung makakuha siya ng kaukulang pahintulot. Ang Google at Apple ay patuloy na nag-a-update ng mga patakaran para sa naturang mga serbisyo.

Sa kabila ng mga limitasyon, ang sandbox ay isang kritikal na component ng seguridad ng mobile operating system. Ayon sa Android Security Report (2024), ang sandbox isolation ay pumipigil sa higit sa 99% ng mga pagtatangka ng inter-app access sa data. Sa kombinasyon sa Code Signing, App Review at runtime permissions, ang Sandbox ay bumubuo ng multi-layered na proteksyon ng modernong mobile device.