Service Contexts

本文面向已经读过安全上下文、TE规则语法、File Contexts、Property Contexts 和 Binder 系列基础文章的读者。前文说明路径、属性名如何映射到 Context；本篇聚焦系统 Binder 的名字空间：service_contexts 如何把 activity、android.hardware.power.IPower/default 这样的服务名映射到 service_manager 对象类的 target Context，servicemanager 如何据此检查 add/find/list，服务表何时更新，以及 lazy service、VINTF accessor 和死亡回调如何改变结束路径。

本文不讨论 hwservice_contexts 或 vndservice_contexts 的完整实现，它们分别属于后续专题。也不把 service_manager add/find 和服务对象真正执行 Binder transaction 的 binder call 混为一谈：前者由 servicemanager 使用 service_contexts 授权名字空间操作，后者由 Binder 驱动和目标进程的 process/domain policy 消费。读完后，读者应能从一个服务名追到文本条目、分区 module、selabel_lookup()、Access::actionAllowed()、ServiceManager 的状态表和错误返回，并能定位“服务未注册”“注册被拒绝”“查找被拒绝”“找到服务但调用被拒绝”四种不同故障。

1. 名字与对象

1.1 服务名

service_contexts 的 key 是 servicemanager 接口使用的字符串。Framework 服务通常使用短名；AIDL/HAL 服务使用接口全名加实例名。两者在 lookup 层没有不同的安全机制，都会作为同一个 service_manager backend 的 key。

源码文件：system/sepolicy/private/service_contexts

text

activity                                  u:object_r:activity_service:s0
window                                    u:object_r:window_service:s0
android.hardware.power.IPower/default     u:object_r:hal_power_service:s0
android.hardware.camera.provider.ICameraProvider/internal/0 \
                                           u:object_r:hal_camera_service:s0
*                                         u:object_r:default_android_service:s0

最后的 * 是服务 backend 的默认 Context；它不自动给予任何域 add 或 find 权限。target type 仍必须在 policy 中具有 service_manager_type attribute，调用者还必须满足相应 access vector。

1.2 三种权限

servicemanager 对名字空间暴露三种与本篇直接相关的权限：

权限	消费者	作用
`add`	`ServiceManager::addService()`	将 binder 对象写入名字到服务的表
`find`	`getService()`、`checkService()`、通知/连接信息查询	读取名字对应的 binder 对象或请求 lazy 启动
`list`	`listServices()`、debug info	列出服务名或服务调试信息

这三个权限的 target object class 都是 service_manager，target Context 来自 service_contexts。获得 binder 引用之后，客户端再发起 transaction 时还会经过 binder 类的 call 检查；service_contexts 不替代该检查。

1.3 Service表

ServiceManager 的 owner 是 mNameToService，键是服务名，值保存 binder、allowIsolated、dump priority、client 状态和注册者 CallingContext。注册回调和 client 回调分别保存在两个 map 中。

源码文件：frameworks/native/cmds/servicemanager/ServiceManager.h

cpp

using ServiceCallbackMap =
        std::map<std::string, std::vector<RegistrationCallback>>;
using ClientCallbackMap =
        std::map<std::string, std::vector<sp<IClientCallback>>>;
using ServiceMap = std::map<std::string, Service>;

ServiceMap mNameToService;
ServiceCallbackMap mNameToRegistrationCallback;
ClientCallbackMap mNameToClientCallback;
std::unique_ptr<Access> mAccess;

2. 文本条目

2.1 平台服务

Android 17 平台文件包含大量 framework 服务名和 AIDL 服务名。下面只取能说明命名层级的条目，不是服务清单。

源码文件：system/sepolicy/private/service_contexts

text

android.frameworks.stats.IStats/default       u:object_r:fwk_stats_service:s0
android.frameworks.sensorservice.ISensorManager/default \
                                                 u:object_r:fwk_sensor_service:s0
android.system.keystore2.IKeystoreService/default \
                                                 u:object_r:keystore_service:s0
android.system.net.netd.INetd/default          u:object_r:system_net_netd_service:s0
android.os.UpdateEngineService                 u:object_r:update_engine_service:s0
android.security.keystore                      u:object_r:keystore_service:s0

服务名是否带 /instance 是接口注册约定；SELinux 只按最终字符串查找 Context。相同 target type 可以被多个服务名共享，但每个调用者仍需要对该 target type 的 add 或 find 权限。

2.2 条件条目

Contexts 文件经过 M4，因此 release flag 可以控制条目是否进入当前输出。条件没有满足时，源码中存在的名字不会出现在产物中。

源码文件：system/sepolicy/private/service_contexts

text

is_flag_enabled(RELEASE_HARDWARE_BLUETOOTH_RANGING_SERVICE, `
    android.hardware.bluetooth.ranging.IBluetoothChannelSounding/default \
        u:object_r:hal_bluetooth_service:s0
')

is_flag_enabled(RELEASE_AISEAL_FRAMEWORK, `
    aiseal_host u:object_r:aiseal_host_service:s0
    aiseal_internal u:object_r:aiseal_internal_service:s0
')

2.3 默认Context

平台文件通常用 * 提供 default Android service Context。lookup 是否使用它由 selabel backend 决定；如果 backend 没有 handle，servicemanager 不会用任意字符串继续完成 MAC 检查。

源码文件：system/sepolicy/private/service_contexts

text

*                                         u:object_r:default_android_service:s0

3. 分区构建

3.1 输入Module

Soong 为 platform、system_ext、product、vendor 和 odm 分别注册 service_contexts module。分区属性决定输入 filegroup 和安装变体；运行时 system/vendor ServiceManager 再选择对应 handle。

源码文件：system/sepolicy/contexts/Android.bp

make

service_contexts {
    name: "plat_service_contexts",
    defaults: ["contexts_flags_defaults"],
    srcs: [":service_contexts_files{.plat_private}"],
}

service_contexts {
    name: "system_ext_service_contexts",
    defaults: ["contexts_flags_defaults"],
    srcs: [":service_contexts_files{.system_ext_private}"],
    system_ext_specific: true,
}

service_contexts {
    name: "vendor_service_contexts",
    defaults: ["contexts_flags_defaults"],
    srcs: [
        ":service_contexts_files{.plat_vendor}",
        ":service_contexts_files{.vendor}",
        ":service_contexts_files{.reqd_mask}",
    ],
    soc_specific: true,
}

3.2 通用生成

service_contexts 使用 buildServiceContexts()，默认把 Remove_comment 设为 true，再复用 buildGeneralContexts() 的 newline、M4、release flag 和注释清理。service contexts 不使用 file contexts 的 fc_sort 分支。

源码文件：system/sepolicy/build/soong/selinux_contexts.go

func (m *selinuxContextsModule) buildServiceContexts(
        ctx android.ModuleContext, inputs android.Paths) android.Path {
    if m.properties.Remove_comment == nil {
        m.properties.Remove_comment = proptools.BoolPtr(true)
    }
    return m.buildGeneralContexts(ctx, inputs)
}

func serviceFactory() android.Module {
    m := newModule()
    m.build = m.buildServiceContexts
    return m
}

3.3 测试Module

service contexts 测试使用 checkfc -s，而不是 file contexts 的默认 backend。-s 表示 binder service backend；测试加载编译 policy，验证 target type 属于 service_manager_type。

源码文件：system/sepolicy/build/soong/selinux_contexts.go

case ServiceContext:
    flags = []string{"-s" /* binder services */}
case HwServiceContext:
    flags = []string{"-e" /* allow empty */, "-l" /* hwbinder services */}
case VndServiceContext:
    flags = []string{"-e" /* allow empty */, "-v" /* vnd service */}

4. Libselinux加载

4.1 路径选择

libselinux 为 service contexts 定义正式路径。Android 17 的实现按分区选择存在的文件，再交给 Android service label backend；vendor ServiceManager 使用 vendor 变体。

源码文件：external/selinux/libselinux/src/android/android.c

static const path_alts_t service_context_paths = { .paths = {
    { "/system/etc/selinux/plat_service_contexts", "/plat_service_contexts" },
    { "/system_ext/etc/selinux/system_ext_service_contexts", "/system_ext_service_contexts" },
    { "/product/etc/selinux/product_service_contexts", "/product_service_contexts" },
    { "/vendor/etc/selinux/vendor_service_contexts", "/vendor_service_contexts" },
    { "/odm/etc/selinux/odm_service_contexts", "/odm_service_contexts" },
}};

4.2 Handle缓存

Access 缓存一个 selabel_handle。SELinux 状态更新后，旧 handle 被关闭，下一次操作重新打开；服务表中的已有 binder 不会因为 handle 刷新而自动重注册。

源码文件：frameworks/native/cmds/servicemanager/Access.cpp

cpp

static struct selabel_handle* getSehandle() {
    static struct selabel_handle* gSehandle = nullptr;
    if (gSehandle != nullptr && selinux_status_updated()) {
        selabel_close(gSehandle);
        gSehandle = nullptr;
    }

    if (gSehandle == nullptr) {
        gSehandle = kIsVendor
            ? selinux_android_vendor_service_context_handle()
            : selinux_android_service_context_handle();
    }

    CHECK(gSehandle != nullptr);
    return gSehandle;
}

4.3 Lookup失败

服务名 lookup 失败时，Access 记录 No match for ... in service_contexts 并返回 false；它不会把未匹配的名字当作允许。

源码文件：frameworks/native/cmds/servicemanager/Access.cpp

cpp

bool Access::actionAllowedFromLookup(const CallingContext& sctx,
                                     const std::string& name,
                                     const char* perm) {
    char* tctx = nullptr;
    if (selabel_lookup(getSehandle(), &tctx, name.c_str(),
                       SELABEL_CTX_ANDROID_SERVICE) != 0) {
        LOG(ERROR) << "SELinux: No match for " << name
                   << " in service_contexts.\n";
        return false;
    }

    bool allowed = actionAllowed(sctx, tctx, perm, name);
    freecon(tctx);
    return allowed;
}

5. Access判定

5.1 Caller Context

source SID 来自 Binder 调用者，优先从 IPCThreadState 读取；target Context 来自服务名 lookup。这两个来源在代码中分别由 getCallingContext() 和 selabel_lookup() 表达。

源码文件：frameworks/native/cmds/servicemanager/Access.cpp

cpp

Access::CallingContext Access::getCallingContext() {
    IPCThreadState* ipc = IPCThreadState::self();
    const char* callingSid = ipc->getCallingSid();
    pid_t callingPid = ipc->getCallingPid();

    return CallingContext{
        .debugPid = callingPid,
        .uid = ipc->getCallingUid(),
        .sid = callingSid ? std::string(callingSid)
                          : getPidcon(callingPid),
    };
}

5.2 MAC调用

actionAllowed() 固定使用 service_manager class，把 add、find 或 list 作为 permission 传入 selinux_check_access()。

源码文件：frameworks/native/cmds/servicemanager/Access.cpp

cpp

bool Access::actionAllowed(const CallingContext& sctx,
                           const char* tctx,
                           const char* perm,
                           const std::string& tname) {
#ifdef __ANDROID__
    const char* tclass = "service_manager";
    AuditCallbackData data{.context = &sctx, .tname = &tname};
    return 0 == selinux_check_access(
            sctx.sid.c_str(), tctx, tclass, perm,
            reinterpret_cast<void*>(&data));
#else
    return true;
#endif
}

5.3 三个入口

canAdd()、canFind() 都按服务名 lookup；canList() 使用 servicemanager 自身 Context 作为 target，因此 list 不是逐服务 find。

源码文件：frameworks/native/cmds/servicemanager/Access.cpp

cpp

bool Access::canFind(const CallingContext& ctx,
                     const std::string& name) {
    return actionAllowedFromLookup(ctx, name, "find");
}

bool Access::canAdd(const CallingContext& ctx,
                    const std::string& name) {
    return actionAllowedFromLookup(ctx, name, "add");
}

bool Access::canList(const CallingContext& ctx) {
    return actionAllowed(ctx, mThisProcessContext,
                         "list", "service_manager");
}

5.4 Target属性

服务 Context 的 type 必须拥有 service_manager_type attribute；API attribute 决定 app domain 的可见范围。

源码文件：system/sepolicy/public/service.te

text

type activity_service, app_api_service, ephemeral_app_api_service,
    system_server_service, service_manager_type;
type window_service, system_api_service,
    system_server_service, service_manager_type;
type hal_power_service, protected_service,
    hal_service_type, service_manager_type;

源码文件：system/sepolicy/private/service.te

text

neverallow domain ~{ service_manager_type vndservice_manager_type }:
    service_manager { add find };