詳解Android應用沙盒機制
前言
Android使用沙盒來保護用戶不受惡意應用的侵害,同時也將應用隔離開來,防止他們互相訪問其數據,本文主要對Android應用沙盒中的幾種技術做簡要的總結。
一、Android應用DAC沙盒
- 稍微瞭解Android一點的人都知道,Android上的App並不像Linux上的用戶程序那樣,啟動應用的uid默認就是登錄用戶的uid,除非你使用sudo或者setuid等機制。而是每個Android應用都對應瞭一個uid,也就是一個用戶,通過Linux系統的DAC機制將應用的數據嚴格隔離開來。
- Android並沒有使用/etc/passwd配置文件以及useradd、usermod和userdel等二進制來管理用戶,這些東西對Android來說過於復雜。實際上Android應用到uid的映射是由PackageManagerService完成的,也就是PMS,並且存儲在/data/system/packages.xml中。
- 將Android應用使用DAC隔離開之後,如果應用要訪問任何系統資源,便會被拒絕,所以Android設計瞭應用權限機制來向應用提供訪問系統資源的通道,同時保護系統資源不被濫用。
- 下面是在Pixel 2 XL (RP1A.201005.004.A1) 上面的一些例子
u:r:untrusted_app:s0:c161,c256,c512,c768 u0_a161 16613 887 14608676 86088 0 0 S com.google.android.apps.photos u:r:untrusted_app:s0:c138,c256,c512,c768 u0_a138 17204 888 1402772 138956 0 0 S com.android.chrome
可以看到相冊應用的用戶為u0_a161,而Chrome瀏覽器應用的用戶為u0_a138
二、Android應用權限
Android應用權限的核心類型分為四種:普通權限、危險權限、簽名權限、簽名或系統權限
權限類型 | 權限行為 |
---|---|
普通權限(Normal) | 普通權限是隻需要在AndroidManifest.xml中聲明後就可以使用的權限。 |
危險權限(dangerous) | 危險權限除瞭需要在AndroidManifest.xml中聲明之外,在Android 6.0或更高版本還需要使用動態權限API進行申請,並且用戶點擊同意之後才能使用;在Android 5.1以及更早版本,會在安裝時單獨列出危險權限以特別提醒用戶。註意,如果自定義權限設置為瞭危險權限,無論Android版本是多少都隻是會在安裝時單獨列出危險權限。 |
簽名權限(signature) | 簽名權限僅會授予給與定義這個權限的包相同簽名的應用。 |
簽名或系統權限(signatureOrSystem) | signature|privileged的舊同義詞。簽名或系統權限與簽名權限唯一的區別就是,簽名或系統權限也允許授予給特權應用(priv_app),該字段現已棄用。 |
在自定義權限中,經常使用簽名權限來保護敏感的接口,使其隻能被可信的應用調用——那些具備和定義權限者相同簽名的應用。
三、應用信息的存儲
應用信息的存儲上文已經提到,位於/data/system/packages.xml中,這裡面存儲瞭應用的各種信息,下面是一個示例:
<package name="com.android.storagemanager" codePath="/system/priv-app/StorageManager" nativeLibraryPath="/system/priv-app/StorageManager/lib" publicFlags="541605445" privateFlags="8" ft="165151eba60" it="165151eba60" ut="165151eba60" version="29" user appUseNotchMode="0" appUseSideMode="1" hwExtraFlags="0" isOrphaned="true" forceDarkMode="2"> <sigs count="1" schemeVersion="1"> <cert index="13" /> </sigs> <perms> <item name="android.permission.USE_RESERVED_DISK" granted="true" flags="0" /> <!-- ... --> </perms> <proper-signing-keyset identifier="3" /> </package> <package name="com.android.settings" codePath="/system/priv-app/Settings" nativeLibraryPath="/system/priv-app/Settings/lib" publicFlags="675823173" privateFlags="8" ft="165151eba60" it="165151eba60" ut="165151eba60" version="10010400" sharedUser appUseNotchMode="0" appUseSideMode="1" hwExtraFlags="0" isOrphaned="true" forceDarkMode="2"> <sigs count="1" schemeVersion="1"> <cert index="0" /> </sigs> <perms> <item name="android.permission.REAL_GET_TASKS" granted="true" flags="0" /> <!-- ... --> </perms> <proper-signing-keyset identifier="1" /> </package>
- 可以看到這個文件中存儲有很多內容,最關鍵的信息包括應用的uid、包名、各類路徑,以及定義和授予的權限。
- 例如StorageManager這個應用的uid是10036,而設置的uid是1000,也就是system的uid。
四、應用權限的映射
- 我們知道Android使用的是Linux內核,而在Linux的安全模型中,如果需要訪問系統資源,訪問系統資源的用戶和進程必須具備相應的權限。
- Android如何將自行定義的Android權限映射到Linux層面的權限呢?答案就位於/etc/permissions/platform.xml中,下面是該文件的節選:
<permission name="android.permission.BLUETOOTH_ADMIN" > <group g /> </permission> <permission name="android.permission.BLUETOOTH" > <group g /> </permission>
這裡顯示的就是,Android的兩個藍牙權限,分別對應瞭net_bt_admin和net_bt兩個Linux組,在應用被授予相應的權限時,PMS會自動將應用uid加入這兩個組中,這樣應用就擁有瞭相應系統資源的訪問權限瞭。
五、應用的SELinux標簽
在Android引入SELinux之後,對應用權限的劃分更為細致,Android默認將應用分為四種:不可信應用、特權應用、平臺應用和系統應用。
SELinux標簽 | 標簽行為 |
---|---|
不可信應用(untrusted_app) | 不可信應用擁有最少的特權,訪問系統資源受到嚴格限制,所有用戶安裝的應用以及部分預裝應用都屬於此標簽。 |
特權應用(priv-app) | 特權應用位於/system/priv-app目錄或OEM定義的其它目錄下,不可卸載,但不以system uid運行。 |
平臺應用(platform_app) | 平臺應用具備平臺簽名,但不以system uid運行。除瞭AOSP和部分第三方ROM之外,幾乎所有的OEM都不會公開其平臺私鑰,所以一般情況下平臺應用隻能是OEM提供的。 |
系統應用(system_app) | 系統應用既具備平臺簽名,又以system uid運行(配置android:sharedUserId=”android.uid.system”)。使用system uid運行意味著它們可以不受應用沙盒的限制,並能訪問絕大部分Android框架中的系統資源。 |
下面是在Pixel 2 XL (RP1A.201005.004.A1) 上面的一些例子
可以得出以下結論:
- Chrome在這臺手機上是untrusted_app
- 啟動器nexuslauncher在這臺手機上是priv_app
- systemui在這臺手機上是platform_app
- 設置settings在這臺手機上是system_app
顯然其中隻有設置是以system uid運行的,其它進程使用的都是普通的應用uid。
六、Android應用MAC沙盒
上面所說的SELinux標簽,Android在源代碼中為它們定義瞭不同的SELinux政策,這便實現瞭MAC層面的沙盒增強。
以上就是詳解Android應用沙盒機制的詳細內容,更多關於Android應用沙盒機制的資料請關註WalkonNet其它相關文章!
推薦閱讀:
- None Found