第四章 Android 框架層安全
譯者：飛龍
如我們在第1.2節中所描述的那樣，應用程序框架級別上的安全性由 IPC 引用監視器實現。 在 4.1 節中，我們以 Android 中使用的進程間通信系統的描述開始，講解這個級別上的安全機制。 之后，我們在 4.2 節中引入權限，而在 4.3 節中，我們描述了在此級別上實現的權限實施系統。
4.1 Android Binder 框架
如 2.1 節所述，所有 Android 應用程序都在應用程序沙箱中運行。粗略地說，應用程序的沙箱通過在帶有不同 Linux 身份的不同進程中運行所有應用程序來保證。此外，系統服務也在具有更多特權身份的單獨進程中運行，允許它們使用 Linux Kernel DAC 功能，訪問受保護的系統不同部分（參見第 2.1, 2.2 和 1.2 節）。因此，需要進程間通信（IPC）框架來管理不同進程之間的數據和信號交換。在 Android 中，一個稱為 Binder 的特殊框架用于進程間通信[12]。標準的 Posix System V IPC 框架不支持由 Android 實現的 Bionic libc 庫（參見[這里](https://android.googlesource.com/platform/ndk/+/android-4.2.2_r1.2/docs/system/ libc/SYSV-IPC.html)）。此外，除了用于一些特殊情況的 Binder 框架，也會使用 Unix 域套接字（例如，用于與 Zygote 守護進程的通信），但是這些機制不在本文的考慮范圍之內。
Binder 框架被特地重新開發來在 Android 中使用。 它提供了管理此操作系統中的進程之間的所有類型的通信所需的功能。 基本上，甚至應用程序開發人員熟知的機制，例如Intents和ContentProvider，都建立在 Binder 框架之上。 這個框架提供了多種功能，例如可以調用遠程對象上的方法，就像本地對象那樣，以及同步和異步方法調用，Link to Death（某個進程的 Binder 終止時的自動通知），跨進程發送文件描述符的能力等等[12,16] 。
根據由客戶端 - 服務器同步模型組織的進程之間的通信。客戶端發起連接并等待來自服務端的回復。 因此，客戶端和服務器之間的通信可以被想象為在相同的進程線程中執行。 這為開發人員提供了調用遠程對象上的方法的可能性，就像它們是本地的一樣。 通過 Binder 的通信模型如圖 4.1 所示。 在這個圖中，客戶端進程 A 中的應用程序想要使用進程 B [12]中運行的服務的公開行為。
使用 Binder 框架的客戶端和服務之間的所有通信，都通過 Linux 內核驅動程序/dev/binder進行。此設備驅動程序的權限設置為全局可讀和可寫（見 3.1 節中的清單 3.3 中的第 3 行）。因此，任何應用程序可以寫入和讀取此設備。為了隱藏 Binder 通信協議的特性，libbinder庫在 Android 中使用。它提供了一種功能，使內核驅動程序的交互過程對應用程序開發人員透明。尤其是，客戶端和服務器之間的所有通信通過客戶端側的代理和服務器側的樁進行。代理和樁負責編碼和解碼數據和通過 Binder 驅動程序發送的命令。為了使用代理和樁，開發人員只需定義一個 AIDL 接口，在編譯應用程序期間將其轉換為代理和樁。在服務端，調用單獨的 Binder 線程來處理客戶端請求。
從技術上講，使用Binder機制的每個公開服務（有時稱為 Binder 服務）都分配有標識。內核驅動程序確保此 32 位值在系統中的所有進程中是唯一的。因此，此標識用作 Binder 服務的句柄。擁有此句柄可以與服務交互。然而，為了開始使用服務，客戶端首先必須找到這個值。服務句柄的發現通過 Binder 的上下文管理器（servicemanager是 Android Binder 的上下文管理器的實現，在這里我們互換使用這些概念）來完成。上下文管理器是一個特殊的 Binder 服務，其預定義的句柄值等于 0（指代清單 4.1 的第 8 行中獲得的東西）。因為它有一個固定的句柄值，任何一方都可以找到它并調用其方法?；旧?，上下文管理器充當名稱服務，通過服務的名稱提供服務句柄。為了實現這個目的，每個服務必須注冊上下文管理器（例如，使用第 26 行中的ServiceManager類的addService方法）。因此，客戶端可以僅知道與其通信的服務名稱。使用上下文管理器來解析此名稱（請參閱getService第 12 行），客戶端將收到稍后用于與服務交互的標識。 Binder 驅動程序只允許注冊單個上下文管理器。因此，servicemanager是由 Android 啟動的第一個服務之一（見第 3.1 節）。servicemanager組件確保了只允許特權系統標識注冊服務。
Binder 框架本身不實施任何安全性。 同時，它提供了在 Android 中實施安全性的設施。 Binder 驅動程序將發送者進程的 UID 和 PID 添加到每個事務。 因此，由于系統中的每個應用具有其自己的 UID，所以該值可以用于識別調用方。 調用的接收者可以檢查所獲得的值并且決定是否應該完成事務。 接收者可以調用android.os.Binder.getCallingUid()和android.os.Binder.getCallingPid()[12]來獲得發送者的 UID 和 PID。 另外，由于 Binder 句柄在所有進程中的唯一性和其值的模糊性[14]，它也可以用作安全標識。
1 public final class ServiceManager {
2 ...
3 private static IServiceManager getIServiceManager() {
4 if ( sServiceManager != null ) {
5 return sServiceManager ;
6 }
7 // Find the service manager
8 sServiceManager = ServiceManagerNative.asInterface( BinderInternal.getContextObject() );
9 return sServiceManager ;
10 }
11
12 public static IBinder getService ( String name) {
13 try {
14 IBinder service = sCache . get (name) ;
15 if ( service != null ) {
16 return service ;
17 } else {
18 return getIServiceManager().getService(name);
19 }
20 } catch (RemoteException e) {
21 Log.e(TAG, "error in getService", e);
22 }
23 return null;
24 }
25
26 public static void addService( String name, IBinder service, boolean allowIsolated ) {
27 try {
28 getIServiceManager().addService(name, service, allowIsolated );
29 } catch (RemoteException e) {
30 Log.e(TAG, "error in addService" , e);
31 }
32 }
33 ...
34 }
代碼 4.1：ServiceManager的源碼
4.2 Android 權限
如我們在 2.1 節中所設計的那樣，在 Android 中，每個應用程序默認獲得其自己的 UID 和 GID 系統標識。 此外，在操作系統中還有一些硬編碼的標識（參見清單 3.5）。 這些身份用于使用在 Linux 內核級別上實施的 DAC，分離 Android 操作系統的組件，從而提高操作系統的整體安全性。 在這些身份中，AID SYSTEM最為顯著。 此 UID 用于運行系統服務器（system server），這個組件統一了由 Android 操作系統提供的服務。 系統服務器具有訪問操作系統資源，以及在系統服務器內運行的每個服務的特權，這些服務提供對其他 OS 組件和應用的特定功能的受控訪問。 此受控訪問基于權限系統。
正如我們在 4.1 節中所提及的，Binder 框架向接收方提供了獲得發送方 UID 和 PID 的能力。在一般情況下，該功能可以由服務利用來限制想要連接到服務的消費者。這可以通過將消費者的 UID 和 PID 與服務所允許的 UID 列表進行比較來實現。然而，在 Android 中，這種功能以略微不同的方式來實現。服務的每個關鍵功能（或簡單來說是服務的方法）被稱為權限的特殊標簽保護。粗略地說，在執行這樣的方法之前，會檢查調用進程是否被分配了權限。如果調用進程具有所需權限，則允許調用服務。否則，將拋出安全檢查異常（通常，SecurityException）。例如，如果開發者想要向其應用程序提供發送短信的功能，則必須將以下行添加到應用程序的AndroidManifest.xml文件中：<uses-permission android:name ="android.permission.SEND_SMS"/> 。Android 還提供了一組特殊調用，允許在運行時檢查服務使用者是否已分配權限。
到目前為止所描述的權限模型提供了一種強化安全性的有效方法。 同時，這個模型是無效的，因為它認為所有的權限是相等的。 在移動操作系統的情況下，所提供的功能在安全意義上并不總是相等。 例如，安裝應用程序的功能比發送 SMS 的功能更重要，相反，發送 SMS 的功能比設置警告或振動更危險。
這個問題在 Android 中通過引入權限的安全級別來解決。有四個可能的權限級別：normal，dangerous，signature和signatureOrSystem。權限級別要么硬編碼到 Android 操作系統（對于系統權限），要么由自定義權限聲明中的第三方應用程序的開發者分配。此級別影響是否決定向請求的應用程序授予權限。為了被授予權限，正常的權限可以只在應用程序的AndroidManifest.xml文件中請求。危險權限除了在清單文件中請求之外，還必須由用戶批準。在這種情況下，安裝應用程序期間，安裝包所請求的權限集會顯示給用戶。如果用戶批準它們，則安裝應用程序。否則，安裝將被取消。如果請求權限的應用與聲明它的應用擁有相同簽名，（6.1 中提到了 Android 中的應用程序簽名的用法），系統將授予signature權限。如果請求的權限應用和聲明權限的使用相同證書簽名，或請求應用位于系統映像上，則授予signatureOrSystem權限。因此，對于我們的示例，振動功能被正常級別的權限保護，發送 SMS 的功能被危險級別的權限保護，以及軟件包安裝功能被signatureOrSystem權限級別保護。
4.2.1 系統權限定義
用于保護 Android 操作系統功能的系統權限在框架的AndroidManifest.xml文件中定義，位于 Android 源的frameworks/base/core/res文件夾中。 這個文件的一個摘錄包含一些權限定義的例子，如代碼清單 4.2 所示。 在這些示例中，展示了用于保護發送 SMS，振動器和包安裝功能的權限聲明。
1 <manifest xmlns:android=" http://schemas.android.com/apk/res/android"
2 package="android" coreApp="true" android:sharedUserId="android.uid.system"
3 android:sharedUserLabel="@string/android_system_label ">
4 ...
5 <!?? Allows an application to send SMS messages. ??>
6 <permission android:name="android.permission.SEND_SMS"
7 android:permissionGroup="android.permission?group.MESSAGES"
8 android:protectionLevel="dangerous"
9 android:permissionFlags="costsMoney"
10 android:label="@string/permlab_sendSms"
11 android:description="@string/permdesc _sendSms" />
12 ...
13 <!?? Allows access to the vibrator ??>
14 <permission android:name="android.permission.VIBRATE"
15 android:permissionGroup="android.permission?group.AFFECTS_BATTERY"
16 android:protectionLevel="normal"
17 android:label="@string/permlab_vibrate"
18 android:description="@string/permdesc_vibrate" />
19 ...
20 <!?? Allows an application to install packages. ??>
21 <permission android:name="android.permission.INSTALL_PACKAGES"
22 android:label="@string/permlab_installPackages"
23 android:description="@string/permdesc_installPackages"
24 android:protectionLevel="signature|system" />
25 ...
26 </manifest>
代碼 4.2：系統權限的定義
默認情況下，第三方應用程序的開發人員無法訪問受signature和signatureOrSystem級別的系統權限保護的功能。 這種行為以以下方式來保證：應用程序框架包使用平臺證書簽名。 因此，需要使用這些級別的權限保護的功能的應用程序必須使用相同的平臺證書進行簽名。 然而，僅有操作系統的構建者才可以訪問該證書的私鑰，通常是硬件生產者（他們自己定制 Android）或電信運營商（使用其修改的操作系統映像來分發設備）。
4.2.2 權限管理
系統服務PackageManagerService負責 Android 中的應用程序管理。 此服務有助于在操作系統中安裝，卸載和更新應用程序。 此服務的另一個重要作用是權限管理。 基本上，它可以被認為是一個策略管理的要素。 它存儲了用于檢查 Android 包是否分配了特定權限的信息。 此外，在應用程序安裝和升級期間，它執行一堆檢查，來確保在這些過程中不違反權限模型的完整性。 此外，它還作為一個策略判定的要素。 此服務的方法（我們將在后面展示）是權限檢查鏈中的最后一個元素。 我們不會在這里考慮PackageManagerService的操作。 然而，感興趣的讀者可以參考[15,19]來獲得如何執行應用安裝的更多細節。
PackageManagerService將所有第三方應用程序的權限的相關信息存儲在/data/system/packages.xml[7]中。 該文件用作系統重新啟動之間的永久存儲器。 但是，在運行時，所有有關權限的信息都保存在 RAM 中，從而提高系統的響應速度。 在啟動期間，此信息使用存儲在用于第三方應用程序的packages.xml文件中的數據，以及通過解析系統應用程序來收集。
4.2.3 Android 框架層的權限實施
為了了解 Android 如何在應用程序框架層強制實施權限，我們考慮 Vibrator 服務用法。 在清單 4.3 的第 6 行中，展示了振動器服務如何保護其方法vibrate的示例。 這一行檢查了調用組件是否分配有由常量android.Manifest.permission.VIBRATE定義的標簽android.permission.VIBRATE。 Android 提供了幾種方法來檢查發送者（或服務使用者）是否已被分配了權限。 在我們這個庫，這些設施由方法checkCallingOrSelfPermission表示。 除了這種方法，還有許多其他方法可以用于檢查服務調用者的權限。
1 public class VibratorService extends IVibratorService.Stub
2 implements InputManager.InputDeviceListener {
3 ...
4 public void vibrate ( long milliseconds, IBinder token ) {
5 if (mContext.checkCallingOrSelfPermission(android.Manifest.permission.VIBRATE)
6 != PackageManager.PERMISSION_GRANTED) {
7 throw new SecurityException("Requires VIBRATE permission");
8 }
9 ...
10 }
11 ...
12 }
代碼 4.3：權限的檢查
方法checkCallingOrSelfPermission的實現如清單 4.4 所示。 在第 24 行中，方法checkPermission被調用。 它接收uid和pid作為 Binder 框架提供的參數。
1 class ContextImpl extends Context {
2 ...
3 @Override
4 public int checkPermission ( String permission, int pid, int uid ) {
5 if ( permission == null ) {
6 throw new IllegalArgumentException ("permission is null ") ;
7 }
8
9 try {
10 return ActivityManagerNative.getDefault().checkPermission(
11 permission, pid, uid );
12 } catch (RemoteException e) {
13 return PackageManager.PERMISSION_DENIED;
14 }
15 }
16
17 @Override
18 public int checkCallingOrSelfPermission ( String permission ) {
19 if ( permission == null ) {
20 throw new IllegalArgumentException("permission is null");
21 }
22
23 return checkPermission( permission, Binder. getCallingPid(),
24 Binder.getCallingUid() );
25 }
26 ...
27 }
代碼 4.4：ContextImpl類的摘錄
在第 11 行中，檢查被重定向到ActivityManagerService類，繼而在ActivityManager組件的方法checkComponentPermission中執行實際檢查。 此方法的代碼如清單 4.5 所示。 在第 4 行中它檢查調用者 UID 是否擁有特權。 具有 root 和系統 UID 的組件由具有所有權限的系統授予。
1 public static int checkComponentPermission ( String permission, int uid,
2 int owningUid, boolean exported ) {
3 // Root , system server get to do everything .
4 if ( uid == 0 || uid == Process.SYSTEM_UID) {
5 return PackageManager.PERMISSION_GRANTED;
6 }
7 // Isolated processes don ’ t get any permissions .
8 if ( UserId.isIsolated ( uid ) ) {
9 return PackageManager.PERMISSION_DENIED;
10 }
11 // If there is a uid that owns whatever is being accessed , it has
12 // blanket access to it regardless of the permissions it requires .
13 if (owningUid >= 0 && UserId.isSameApp(uid, owningUid) ) {
14 return PackageManager.PERMISSION_GRANTED;
15 }
16 // If the target is not exported , then nobody else can get to it .
17 if (!exported) {
18 Slog.w(TAG, "Permission denied: checkComponentPermission() owningUid=" + owningUid) ;
19 return PackageManager.PERMISSION_DENIED;
20 }
21 if ( permission == null ) {
22 return PackageManager.PERMISSION_GRANTED;
23 }
24 try {
25 return AppGlobals.getPackageManager()
26 .checkUidPermission ( permission , uid ) ;
27 } catch (RemoteException e) {
28 // Should never happen , but if it does . . . deny !
29 Slog.e(TAG, "PackageManager is dead ?!?" , e) ;
30 }
31 return PackageManager.PERMISSION_DENIED;
32 }
代碼 4.5：ActivityManager的checkComponentPermission方法。
在清單 4.5 的第 26 行中，權限檢查被重定向到包管理器，將其轉發到PackageManagerService。 正如我們前面解釋的，這個服務知道分配給 Android 包的權限。 執行權限檢查的PackageManagerService方法如清單 4.6 所示。 在第 7 行中，如果將權限授予由其 UID 定義的 Android 應用程序，則會執行精確檢查。
1 public int checkUidPermission ( String permName, int uid ) {
2 final boolean enforcedDefault = isPermissionEnforcedDefault(permName);
3 synchronized (mPackages) {
4 Object obj = mSettings.getUserIdLPr( UserHandle.getAppId( uid ) );
5 if ( obj != null ) {
6 GrantedPermissions gp = ( GrantedPermissions ) obj ;
7 if (gp.grantedPermissions.contains (permName) ) {
8 return PackageManager.PERMISSION_GRANTED;
9 }
10 } else {
11 HashSet<String> perms = mSystemPermissions.get ( uid ) ;
12 if (perms != null && perms.contains (permName) ) {
13 return PackageManager.PERMISSION_GRANTED;
14 }
15 }
16 if (!isPermissionEnforcedLocked (permName, enforcedDefault ) ) {
17 return PackageManager.PERMISSION_GRANTED;
18 }
19 }
20 return PackageManager .PERMISSION DENIED;
21 }
代碼 4.6：PackageManagerService的checkUidPermission方法
