超越“门禁”：构建零信任的 Binder 安全架构

一句话总结：

现代 Binder 安全架构，不仅要建好“公司门禁”严防外部入侵，更要奉行“零信任”原则——默认不相信任何人，对进入内部的每一次操作都进行严格的权限校验、身份追溯和输入验证。

---

一、基础防线：“访问控制”四件套（传统的“门禁”系统）

1. 身份标识 (UID/PID): 内核保证的、不可伪造的调用方身份。
2. 框架权限: 在 AndroidManifest.xml 中声明 android:permission，由系统 PackageManager 强制执行。
3. 签名权限 (protectionLevel="signature"): 确保只有与你使用相同证书签名的应用才能访问。
4. SELinux 强制访问控制: 由系统底层提供的、超越传统 Linux 权限的最终防线。

这套“门禁”系统能挡住绝大部分外部攻击。但真正的挑战在于，当一个请求通过了门禁之后，我们该如何继续保证安全？

---

二、核心思想跃迁：从“守门”到“内部审计”的零信任模型

零信任（Zero Trust）的核心思想是： “永不信任，永远验证” 。我们必须假设：

• 授权的客户端也可能被恶意利用。
• 任何传入的数据都可能是恶意的。
• 系统服务等“特权邻居”也可能被当成攻击跳板。

基于此，我们需要在服务内部构建一套严密的“内部审计”机制。

三、零信任架构下的三大核心实践

实践一：最小权限原则——从“服务级”到“方法级”的权限管控

不要给服务一把“万能钥匙”。应该根据操作的敏感程度，为 AIDL 中的不同方法设计不同的权限。

设计示例：

// 定义两个不同级别的权限
<permission android:name="com.example.permission.READ_DATA" ... />
<permission android:name="com.example.permission.WRITE_DATA" ... />

// 在 AIDL 接口中（概念上）对应不同方法
interface IMyService {
    // 读取操作，需要读权限
    String readData(int id);
    
    // 写入操作，需要更高风险的写权限
    void writeData(int id, String data);
}

服务端实现： 在 onTransact 中，根据 code（方法ID）来检查对应的权限。

@Override
protected boolean onTransact(int code, Parcel data, Parcel reply, int flags) {
    switch (code) {
        case TRANSACTION_readData:
            // 检查读权限
            getContext().enforceCallingPermission("com.example.permission.READ_DATA", "Read access denied");
            // ... 执行读逻辑 ...
            return true;
        case TRANSACTION_writeData:
            // 检查写权限
            getContext().enforceCallingPermission("com.example.permission.WRITE_DATA", "Write access denied");
            // ... 执行写逻辑 ...
            return true;
    }
    return super.onTransact(code, data, reply, flags);
}

实践二：输入验证——默认所有传入数据都有“毒”

所有从 Parcel 中解包出来的数据都是不可信的。即使是授权客户端，也可能因为 Bug 或被攻击而发送异常数据。

• 检查空值： 字符串、列表等是否为 null？
• 检查边界： 索引、大小、数值是否在预期范围内？
• 检查格式： 字符串是否包含非法字符？

// 在 onTransact 或具体的业务方法中
data.enforceInterface(DESCRIPTOR);
int id = data.readInt();
String content = data.readString();

// 必须进行验证！
if (id < 0 || id > MAX_ID) {
    throw new SecurityException("ID out of bounds");
}
if (content == null || content.length() > MAX_CONTENT_LENGTH) {
    throw new SecurityException("Invalid content");
}
// ... 验证通过后，才能使用 ...

实践三：防御“被迷惑的代理人”——追踪真实的调用者

这是 Binder 安全中最关键也最容易被忽视的一环。当你的服务被其他服务（尤其是系统服务）调用时，必须警惕“身份”可能被“借用”。

getCallingUid() 的陷阱：

A (UID 10100) -> B (系统 UID 1000) -> C (你的服务)

在 C 中调用 getCallingUid()，得到的是 1000（B的UID），而不是 10100（A的UID）。

防御机制：

1. 明确契约： 如果你的服务只应被系统调用，那么检查 getCallingUid() < Process.SYSTEM_UID 是正确的。
2. 传递身份： 如果你的服务需要知道原始调用者，那么中间服务（B）必须有机制将原始身份（A的UID）作为参数明确传递给你。
3. 小心使用身份重置： Binder.clearCallingIdentity() 会暂时清除调用者身份，让当前服务的后续调用看起来像是“自己调用自己”。这是一个强大的工具，但也极度危险。使用它之后，必须在 finally 块中调用 Binder.restoreCallingIdentity() ，否则会导致调用身份“泄漏”，给后续代码带来严重的安全隐患。

---

四、总结：从“安全清单”到“安全思维”的转变

旧思维（访问控制）	新思维（零信任架构）
目标	阻止未经授权的访问
身份	getCallingUid() 是谁，就信任谁
权限	给整个服务授予一个权限
数据	信任来自授权客户端的数据
模型	坚固的城墙

构建安全的 Binder 服务，不仅是实现一个功能，更是要用系统性的、怀疑的眼光去设计每一次跨进程交互。