モバイル開発における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アクセスがある場合、攻撃者はスーパーユーザー特権を取得するため、サンドボックスをバイパスできます。

2つ目の制限は悪意のあるパーミッションです。ユーザーがアプリケーションに連絡先やマイクへのアクセスを許可した場合、アプリケーションは正当なシステムAPIを使用しているため、サンドボックスはこのデータの収集を防ぐことができません。この場合の保護は、ユーザーの認識レベルとApp StoreおよびGoogle Playのレビュープロセスに移行します。

3つ目の制限はサンドボックス間の相互作用です。一部のシステムサービス（NotificationListenerService、AccessibilityService）は、他のアプリケーションのデータへの拡張アクセス権を持っています。攻撃者は適切なパーミッションを取得すれば、これらのサービスを使用してサンドボックスをバイパスする可能性があります。GoogleとAppleはそのようなサービスのポリシーを継続的に更新しています。

制限にもかかわらず、サンドボックスはモバイルOSの重要なセキュリティコンポーネントです。Android Security Report（2024）によると、サンドボックス分離は99%以上のアプリケーション間データアクセス試行を防止します。コード署名、アプリレビュー、実行時パーミッションと組み合わせることで、Sandboxは最新のモバイルデバイスの多層保護を形成します。