2. Linux内核权限模型基础

在驱动开发中，权限检查是安全的第一道防线。Linux内核的权限模型经历了从传统超级用户模型到细粒度capability机制，再到可插拔的LSM框架的演进。理解这三层结构，是编写安全驱动的基石。

2.1 传统进程权限模型：UID/GID与超级用户

Linux进程使用用户ID（UID）和组ID（GID）标识身份。内核通过比较进程的UID与目标资源的owner/group来决定是否允许操作。

传统模型的致命缺陷是“全有或全无”：一旦进程获得root权限，就可以执行任何操作。一个需要打开原始套接字的网络监控程序，如果以root运行，同时也拥有了修改系统时间、加载内核模块等本不需要的能力。

2.2 Capability机制：最小权限的工程实现

Capability机制将root的无限权力分割为独立的单元。每个单元代表一项特权操作。进程的cred结构体中包含一个capability位图，内核在检查权限时，不再问“你是不是root？”，而是问“你有没有这个capability？”

2.2.1 常用Capability与驱动场景

2.2.2 驱动中的Capability检查API

在驱动代码中，使用 capable() 函数进行权限检查。该函数检查当前进程的effective capability集合中是否包含指定的capability。

#include <linux/security.h>

static long mydev_ioctl(struct file *filp, unsigned int cmd, unsigned long arg)
{
    switch (cmd) {
    case MYDEV_SET_HW_CONFIG:
        // 检查调用进程是否有CAP_SYS_ADMIN能力
        if (!capable(CAP_SYS_ADMIN))
            return -EPERM;
        // 执行硬件配置操作
        break;
    case MYDEV_READ_STATUS:
        // 普通状态读取，不需要特殊权限
        break;
    default:
        return -ENOTTY;
    }
    return 0;
}

2.3 LSM框架：可插拔的安全策略引擎

LSM（Linux Security Module）是一个内核安全框架，它在关键内核操作路径上插入钩子（hooks），允许安全模块在这些钩子中实施自定义的访问控制策略。SELinux、AppArmor、Smack都是基于LSM实现的安全模块。

2.3.1 LSM钩子与驱动的关系

当驱动调用 capable() 时，LSM框架会介入。实际上，capable() 内部会调用 security_capable() 这个LSM钩子。如果系统启用了SELinux，SELinux模块会在这个钩子中执行额外的策略检查。

2.3.2 驱动开发需要关注的LSM钩子

虽然驱动开发者通常不需要直接调用LSM钩子，但理解以下钩子有助于调试权限问题：

2.4 三层权限模型的协作关系

在驱动运行时，权限检查是分层进行的。理解这个协作关系，有助于定位“为什么我的驱动返回-EPERM？”这类问题。

1. DAC检查（传统UID/GID）： 内核VFS层首先检查进程是否有权打开设备节点（文件权限位）。
2. Capability检查： 驱动代码中显式调用 capable()，检查进程是否拥有特定特权。
3. LSM检查： 如果系统启用了SELinux等模块，LSM钩子会执行额外的安全策略。即使前两步通过，LSM仍可能拒绝操作。

2.5 本章小结

Linux内核权限模型为驱动开发提供了清晰的权限检查路径：

• 传统DAC模型提供基础的UID/GID检查，但粒度太粗。
• Capability机制将root权限细分为独立单元，驱动应使用 capable() 进行最小权限检查。
• LSM框架在内核关键路径上插入钩子，允许SELinux等模块实施更强的安全策略。