第16章 Camera安全与权限管理

课程目录第16章 Camera安全与权限管理

Camera安全与权限管理：从底层到框架的全面防护

大家好，我是你们的老朋友。今天我们来聊聊Camera安全与权限管理这个话题。说实话，我在做Camera驱动开发的早期，对安全这块重视程度不够，总觉得「能跑就行」。直到有一次，一个第三方应用通过漏洞直接访问了摄像头硬件，我才意识到——安全不是锦上添花，而是底线。

这一章，我会从Android权限模型讲起，深入到SELinux策略编写，再到安全摄像头的实现。嗯，内容有点多，但都是干货。

1. Android Camera权限模型：CAMERA与RECORD_AUDIO

Android的权限模型，说白了就是「谁可以碰摄像头」的规则。系统定义了两个核心权限：

CAMERA：访问摄像头硬件，拍照或预览
RECORD_AUDIO：录制音频，通常与视频录制配合使用

这两个权限都是危险权限（Dangerous Permission），需要运行时申请。为什么？因为摄像头和麦克风涉及用户隐私，不能偷偷用。

关键点：从Android 6.0（API 23）开始，危险权限必须在运行时动态申请，光在Manifest里声明是不够的。

我在项目中遇到过一个问题：某个App申请了CAMERA权限，但没申请RECORD_AUDIO，结果录像时只有画面没有声音。用户还以为是手机坏了……其实只是权限没给全。

权限申请流程

应用层调用流程大致如下：

// 检查权限
if (ContextCompat.checkSelfPermission(this, Manifest.permission.CAMERA) 
    != PackageManager.PERMISSION_GRANTED) {
    // 请求权限
    ActivityCompat.requestPermissions(this, 
        new String[]{Manifest.permission.CAMERA}, 
        REQUEST_CAMERA_PERMISSION);
}

但底层是怎么处理的？当应用打开Camera时，CameraService会检查调用方的UID和PID，确认是否有权限。这个过程涉及PermissionController和PackageManagerService的协作。

小提示：在HAL层，我们通常不直接处理权限检查，但需要确保上层传递下来的权限状态是正确的。我曾经见过一个HAL实现，因为没检查权限状态，导致即使应用被拒绝授权，底层仍然能打开摄像头——这是严重的安全漏洞。

2. SELinux策略编写：camera.te

SELinux（Security-Enhanced Linux）是Android安全模型的核心。它通过强制访问控制（MAC）来限制进程的行为。对于Camera来说，我们需要为cameraserver和hal_camera等进程编写SELinux策略。

为什么要写SELinux策略？你想想看，即使应用有CAMERA权限，但如果SELinux策略不允许cameraserver访问/dev/video0，那摄像头还是打不开。这就是「双重保险」。

camera.te 文件示例

# 定义 cameraserver 域
type cameraserver, domain;
type cameraserver_exec, exec_type, file_type;

# 允许 cameraserver 访问摄像头设备
allow cameraserver video_device:chr_file rw_file_perms;

# 允许 cameraserver 与 HAL 通信
allow cameraserver hal_camera:unix_dgram_socket sendto;
allow cameraserver hal_camera:binder { call transfer };

# 允许 cameraserver 访问 /data/misc/camera
allow cameraserver camera_data_file:dir create_dir_perms;
allow cameraserver camera_data_file:file create_file_perms;

嗯，这里要注意几个关键点：

domain：定义进程的安全上下文
type：定义文件或资源的类型
allow：授予访问权限

警告：SELinux策略写得太宽松会失去保护作用，写得太严格会导致功能异常。我曾经因为少写了一条allow cameraserver camera_data_file:file write，导致相机应用保存照片时直接崩溃。排查了整整两天……

SELinux策略调试技巧

当SELinux拒绝访问时，可以在dmesg或logcat中看到类似这样的信息：

avc: denied { open } for pid=1234 comm="cameraserver" 
    path="/dev/video0" dev="tmpfs" scontext=u:r:cameraserver:s0 
    tcontext=u:object_r:video_device:s0 tclass=chr_file

这个日志告诉我们：cameraserver试图打开/dev/video0，但被SELinux阻止了。解决方案就是添加对应的allow规则。

我的习惯：在开发阶段，可以临时将SELinux设为宽容模式（permissive），但上线前一定要改回强制模式（enforcing）。宽容模式只是用来排查问题的，不是用来逃避问题的。

3. Camera沙箱与隔离机制

沙箱（Sandbox）是Android隔离应用的核心机制。每个应用运行在自己的进程中，拥有独立的UID和权限。Camera服务也不例外。

Android Camera架构中，cameraserver是一个独立的系统进程，运行在system用户下。它通过Binder与上层应用通信，通过HAL与底层硬件交互。这种设计天然实现了隔离：

应用层：只能通过Camera API访问，无法直接操作硬件
服务层：cameraserver负责权限检查和资源管理
HAL层：硬件抽象层，与硬件直接交互，但受SELinux限制

说白了，就是「各司其职，互不越界」。

隔离机制的实现

在Android 10及以上版本中，Camera HAL运行在独立的hal_camera进程中，与cameraserver分离。这样做的好处是：即使HAL层出现漏洞，攻击者也无法直接控制cameraserver。

我记得有一次，客户反馈说某个第三方相机App会导致系统重启。排查后发现，是HAL层的一个内存越界问题。但因为HAL运行在独立进程中，崩溃只影响了HAL本身，cameraserver通过Binder检测到HAL无响应后，优雅地重启了HAL——这就是隔离机制的价值。

4. 安全摄像头（Secure Camera）实现

安全摄像头，也叫Secure Camera，是Android 12引入的特性。它允许应用在安全环境中处理摄像头数据，防止被其他进程窃取。

实现原理其实不复杂：

应用通过CameraManager创建CameraDevice时，指定SESSION_ID为安全会话
底层HAL将摄像头数据直接传递到安全内存区域（如TEE或TrustZone）
普通应用无法访问安全内存区域，只有经过授权的安全应用才能读取

核心思路：安全摄像头不是「加密传输」，而是「隔离处理」。数据从硬件出来就直接进入安全世界，普通世界根本看不到。

HAL层支持

在HAL层，需要实现ICameraDeviceSession接口中的安全相关方法：

// 检查是否支持安全模式
status_t isSecureCameraSupported(bool* supported) {
    // 检查硬件是否支持TEE
    *supported = (access("/dev/secure_camera", F_OK) == 0);
    return OK;
}

// 配置安全会话
status_t configureSecureSession(
    const StreamConfiguration& config,
    const SecureSessionParams& params) {
    // 将流配置到安全内存区域
    // 注意：这里需要与TEE驱动交互
    return configureStreamToSecureMemory(config, params);
}

注意：安全摄像头的实现高度依赖硬件平台。如果你的SoC不支持TEE或TrustZone，那安全摄像头就是个摆设。我在一个项目中就踩过这个坑——客户要求支持安全摄像头，但硬件平台根本不支持，最后只能通过软件模拟，效果大打折扣。

5. 实战：为Camera HAL编写SELinux策略

好了，理论讲完了，我们来点实战。假设我们要为Camera HAL编写SELinux策略，目标是让hal_camera进程能够访问摄像头设备、与cameraserver通信，并写入日志。

步骤1：定义类型和域

# 在 hal_camera.te 中
type hal_camera, domain;
type hal_camera_exec, exec_type, file_type;

# 定义摄像头设备类型
type video_device, dev_type;
# 定义摄像头数据文件类型
type camera_data_file, file_type, data_file_type;

步骤2：授予基本权限

# 允许 hal_camera 访问 /dev/video*
allow hal_camera video_device:chr_file rw_file_perms;

# 允许 hal_camera 创建和写入日志
allow hal_camera camera_data_file:dir create_dir_perms;
allow hal_camera camera_data_file:file create_file_perms;

# 允许 hal_camera 与 cameraserver 通信
allow hal_camera cameraserver:binder { call transfer };
allow hal_camera cameraserver:unix_dgram_socket sendto;

步骤3：处理特殊情况

有时候，HAL需要访问一些特殊的设备节点，比如ISP（图像信号处理器）或MIPI接口。这些设备可能有独立的类型：

# 允许访问ISP设备
allow hal_camera isp_device:chr_file rw_file_perms;

# 允许访问MIPI控制器
allow hal_camera mipi_ctrl:chr_file rw_file_perms;

避坑指南：我曾经在编写SELinux策略时，漏掉了hal_camera对proc文件系统的访问权限。结果HAL在初始化时读取/proc/cpuinfo失败，导致整个相机服务无法启动。所以，记得加上：

allow hal_camera proc:file read;

步骤4：编译和验证

编写完策略后，需要编译进系统镜像。在BoardConfig.mk中指定：

BOARD_SEPOLICY_DIRS += \
    device/xxx/sepolicy/camera

然后编译、刷机、验证。验证方法很简单：

将SELinux设为强制模式：setenforce 1
打开相机应用，拍照、录像
检查dmesg和logcat中是否有AVC拒绝日志

如果没有拒绝日志，说明策略写对了。如果有，根据日志补充对应的allow规则。

知识体系总览

下面这张图，是我自己整理的Camera安全与权限管理的知识体系。你可以把它当作一个「地图」，随时回来对照：

这张图展示了Camera安全体系的三个层次：应用层负责权限申请，框架层负责服务隔离，安全策略层负责强制访问控制。而安全摄像头则是这三层协同工作的典型场景。

好了，这一章的内容就到这里。安全是个大话题，但核心思路其实很简单：最小权限原则——只给必要的权限，只开必要的接口，只允许必要的访问。记住这一点，你在写Camera驱动时就不会犯大错。

如果你在编写SELinux策略时遇到问题，欢迎随时交流。毕竟，安全这条路，一个人走容易踩坑，大家一起走才踏实。

📚 课程目录

Camera安全与权限管理：从底层到框架的全面防护

1. Android Camera权限模型：CAMERA与RECORD_AUDIO

权限申请流程

2. SELinux策略编写：camera.te

camera.te 文件示例

SELinux策略调试技巧

3. Camera沙箱与隔离机制

隔离机制的实现

4. 安全摄像头（Secure Camera）实现

HAL层支持

5. 实战：为Camera HAL编写SELinux策略

步骤1：定义类型和域

步骤2：授予基本权限

步骤3：处理特殊情况

步骤4：编译和验证

知识体系总览