모바일 개발에서의 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)가 사용됩니다. 커널 수준에서는 SELinux 또는 유사한 메커니즘을 통해 강제 액세스 제어(MAC)가 적용됩니다.

파일 시스템 격리

각 애플리케이션은 장치 파일 시스템에 자체 루트 디렉터리를 받습니다. iOS에서 이 디렉터리는 /var/mobile/Containers/Data/Application/{UUID}이고, Android에서는 /data/data/{package_name}입니다. 애플리케이션은 이 디렉터리 내에서만 파일을 읽고 쓸 수 있습니다. 이 디렉터리 외부의 파일에 대한 액세스는 운영 체제 커널 수준에서 차단됩니다.

시스템은 또한 액세스가 제한된 특별한 공유 디렉터리를 제공합니다. iOS에는 사용자 데이터를 위한 Documents 디렉터리, 설정을 위한 Library, 임시 파일을 위한 Caches가 있습니다. Android에는 — 내부 저장소(getFilesDir)와 외부 저장소(getExternalFilesDir)가 있으며, 액세스에 추가 권한이 필요하지 않습니다.

프로세스 및 UID 격리

Android에서 각 애플리케이션은 고유 UID(사용자 ID)를 가진 별도의 Linux 프로세스로 실행됩니다. UID는 애플리케이션 설치 시 할당되며 전체 수명 주기 동안 변경되지 않습니다. 다른 UID를 가진 프로세스는 커널 수준에서 서로 격리됩니다 — 서로의 메모리나 파일에 액세스할 수 없습니다. iOS에서도 XNU 커널과 보호 시스템을 통해 유사한 메커니즘이 작동합니다.

Android의 추가 보호 계층은 Android 4.3부터 enforcing 모드의 SELinux(Security-Enhanced Linux)에 의해 제공됩니다. 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 모드로 실행되며, 이는 보안 정책의 강제 적용을 의미합니다. 각 애플리케이션에는 보안 컨텍스트가 할당되고 모든 시스템 호출이 정책에 대해 확인됩니다. 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 — 애플리케이션이 엄격하게 정의된 URI를 통해 다른 애플리케이션에 데이터에 대한 액세스를 제공할 수 있는 Android 구성 요소입니다. FileProvider — 파일 시스템 경로를 노출하지 않고 파일을 공유하는 안전한 방법입니다.

샌드박스의 제한 사항 및 보안

App Sandbox는 강력한 보안 메커니즘이지만 근본적인 한계가 있습니다. 샌드박스는 수평적 액세스(애플리케이션 간)로부터 보호하지만, 수직적 액세스(커널 수준의 맬웨어 또는 장치에 대한 물리적 액세스)로부터는 보호하지 않습니다. 탈옥 또는 root 액세스의 경우 공격자가 슈퍼유저 권한을 얻기 때문에 샌드박스를 우회할 수 있습니다.

두 번째 제한 사항은 악성 권한입니다. 사용자가 애플리케이션에 연락처 및 마이크 액세스 권한을 부여하면, 애플리케이션이 합법적인 시스템 API를 사용하기 때문에 샌드박스는 이 데이터 수집을 방지할 수 없습니다. 이 경우 보호는 사용자 인식 수준과 App Store 및 Google Play 검토 프로세스로 이동합니다.

세 번째 제한 사항은 샌드박스 간 상호 작용입니다. 일부 시스템 서비스(NotificationListenerService, AccessibilityService)는 다른 애플리케이션의 데이터에 대한 확장된 액세스 권한을 가집니다. 공격자는 적절한 권한을 얻으면 이러한 서비스를 사용하여 샌드박스를 우회할 수 있습니다. Google과 Apple은 이러한 서비스에 대한 정책을 지속적으로 업데이트합니다.

한계에도 불구하고 샌드박스는 모바일 OS의 중요한 보안 구성 요소입니다. Android Security Report(2024)에 따르면, 샌드박스 격리는 애플리케이션 간 데이터 액세스 시도의 99% 이상을 방지합니다. 코드 서명, 앱 검토 및 런타임 권한과 결합하여 Sandbox는 최신 모바일 장치의 다계층 보호를 형성합니다.