App Sandbox в Ð¼Ð¾Ð±Ñ–Ð»ÑЊÐ½Ñ–Ð¹ ÑЂÐ¾Ð·ÑЂÐ¾Ð±Ñ†Ñ„ ₼ ыо таке, механізм Ñ– Ð¿ÑЂÐ¸Ð½Ñ†Ð¸Ð¿ ÑЂÐ¾Ð±Ð¾Ñ‚Ð¸

Що таке 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 (ID користувача). 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 дозволяє додаткам з однієї групи мати спільний контейнер. Push-сповіщення, iCloud, Apple Pay — всі ці функції вимагають відповідних entitlements.

Важливо зазначити, що entitlements в iOS — це не те же саме, що дозволи (permissions). Дозволи запитуються у користувача під час виконання (наприклад, доступ до камери), а entitlements перевіряються системою на етапі встановлення і не можуть бути змінені користувачем. Entitlement визначається розробником та підписується Apple в процесі ревю додатка.

Пісочниця в Android

Android використовує багаторівневу модель пісочниці, засновану на ядрі Linux. Кожен додаток працює як окремий користувач Linux з унікальним UID, що забезпечує базову ізоляцію на рівні процесів та файлів. Додаткові рівні — SELinux для примусового контролю доступу та Дозволи для контролю доступу до системних API.

SELinux та UID-ізоляція

SELinux в Android працює в режимі enforcing, що означає примусове застосування політик безпеки. Кожному додатку призначається контекст безпеки (security context), і всі системні виклики перевіряються на відповідність політиці. 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 є потужним механізмом захисту, він має фундаментальні обмеження. Пісочниця захищає від горизонтального доступу (додаток-до-додатка), але не від вертикального (шкідливе ПЗ на рівні ядра або фізичний доступ до пристрою). При jailbreak або root-доступі пісочниця може бути обійдена, оскільки зловмисник отримує права суперкористувача.

Друге обмеження — шкідливі дозволи. Якщо користувач надає додатку доступ до контактів та мікрофона, пісочниця не може запобігти збору цих даних, оскільки додаток використовує легітимні системні API. Захист у цьому випадку переходить на рівень обізнаності користувача та процесів ревю App Store та Google Play.

Третє обмеження — взаємодія між пісочницями. Деякі системні служби (NotificationListenerService, AccessibilityService) мають розширений доступ до даних інших додатків. Зловмисник може використовувати ці служби для обходу пісочниці, якщо отримає відповідні дозволи. Google та Apple постійно оновлюють політики для таких служб.

Незважаючи на обмеження, пісочниця є критичним компонентом безпеки мобільних ОС. За даними Android Security Report (2024), ізоляція пісочниці запобігає понад 99% спроб міжпрограмного доступу до даних. У поєднанні з Code Signing, App Review та дозволами часу виконання, Sandbox формує багаторівневий захист сучасного мобільного пристрою.