Linux内核架构浅谈70 - Linux设备驱动安全性：权限控制与设备访问限制

深入理解设备驱动安全机制，从权限设计到访问管控

一、Linux设备驱动安全的核心挑战

在Linux系统中，设备驱动作为内核与硬件交互的"桥梁"，直接操作硬件资源（如磁盘、网卡、USB设备等），其安全性直接决定了整个系统的稳定性与数据安全性。设备驱动面临的核心安全挑战包括：

• 非法进程越权访问硬件，导致数据泄露或硬件损坏；
• 驱动权限设计不当，允许普通用户修改关键硬件配置；
• 设备文件访问控制不严，引发未授权的设备操作；
• 驱动代码中缺乏访问校验，导致恶意程序利用漏洞绕过限制。

为解决这些问题，Linux内核通过"设备文件抽象"、"权限控制机制"和"访问限制策略"构建了多层安全防护体系，确保只有授权进程能合法操作设备。

二、设备文件与权限基础：万物皆文件的安全延伸

Linux遵循"万物皆文件"的设计哲学，所有硬件设备均通过/dev目录下的"设备文件"抽象表示。用户空间进程通过操作设备文件间接与硬件交互，而设备文件的权限配置则成为第一道安全防线。

2.1 设备文件的权限属性

设备文件与普通文件类似，拥有所有者（uid）、所属组（gid）和三类权限（读、写、执行），但"执行权限"对设备文件无实际意义，核心权限为"读（r）"和"写（w）"：

• r：允许进程从设备读取数据（如从键盘读取输入、从磁盘读取文件）；
• w：允许进程向设备写入数据（如向磁盘写入文件、向打印机发送任务）；
• 所有者/组：通过uid和gid限制特定用户或用户组的访问范围。

通过ls -l /dev可查看设备文件的权限配置，例如：

# 字符设备：键盘（crw-rw-r-- 表示所有者/组有读写权限，其他用户仅读）
crw-rw-r-- 1 root root 13, 0  6月 10 10:00 input/event0
# 块设备：磁盘分区（brw-rw---- 表示所有者/组有读写权限，其他用户无权限）
brw-rw---- 1 root disk 8, 0  6月 10 10:00 sda

2.2 设备文件的创建与权限初始化

设备文件通常由内核自动创建（如udev守护进程监测到硬件插入时），或通过mknod命令手动创建。创建时需指定设备类型（字符设备c、块设备b）、主设备号和次设备号，以及初始权限：

# 手动创建字符设备文件：主设备号13（input子系统），次设备号0，权限664（rw-rw-r--）
mknod /dev/my_input c 13 0
# 设置所有者为root，所属组为input
chown root:input /dev/my_input
# 设置权限为664
chmod 664 /dev/my_input

注意：主设备号标识设备驱动（如13对应input子系统），次设备号标识同一驱动下的具体设备（如多个键盘对应不同次设备号）。权限设置需遵循"最小权限原则"，避免过度开放（如磁盘设备不应给普通用户写权限）。

三、驱动层权限控制：从设备注册到请求校验

设备文件的权限仅能限制"是否能访问设备文件"，而驱动层的权限控制则负责校验"访问操作是否合法"。内核通过设备驱动注册、权限检查钩子和访问控制表（ACL）实现精细化管控。

3.1 设备驱动注册时的权限预设

驱动在向内核注册设备时，可通过struct file_operations结构体的open函数预设访问权限校验逻辑。例如，字符设备驱动在chrdev_register注册后，每次进程打开设备文件时，open函数会先检查进程权限：

#include 
#include 
#include 

// 设备打开时的权限校验函数
static int my_device_open(struct inode *inode, struct file *filp) {
    // 仅允许root用户（uid=0）打开设备
    if (current->cred->uid.val != 0) {
        printk(KERN_ERR "my_device: only root can open this device\n");
        return -EPERM; // 权限不足，返回错误码
    }
    printk(KERN_INFO "my_device: opened by root\n");
    return 0;
}

// 文件操作结构体：绑定open函数
static const struct file_operations my_fops = {
    .owner = THIS_MODULE,
    .open = my_device_open,
    // 其他操作（read/write等）...
};

// 驱动初始化：注册字符设备
static int __init my_device_init(void) {
    int ret;
    // 注册主设备号100，设备名"my_device"，绑定file_operations
    ret = register_chrdev(100, "my_device", &my_fops);
    if (ret < 0) {
        printk(KERN_ERR "my_device: register failed\n");
        return ret;
    }
    return 0;
}

module_init(my_device_init);
MODULE_LICENSE("GPL");

上述代码中，my_device_open函数通过current->cred->uid.val获取当前进程的uid，仅允许root用户（uid=0）打开设备，普通用户打开时会返回-EPERM错误。

3.2 基于capability的细粒度权限控制

传统的uid/gid权限体系无法满足复杂场景（如允许普通用户执行特定内核操作），Linux引入"capability"机制，将root权限拆分为多个细粒度的能力（如CAP_NET_RAW允许创建原始网络套接字、CAP_SYS_ADMIN允许系统管理操作）。驱动可通过capable()函数检查进程是否拥有特定能力：

#include 

static int my_device_ioctl(struct file *filp, unsigned int cmd, unsigned long arg) {
    // 仅允许拥有CAP_SYS_ADMIN能力的进程执行IOCTL命令
    if (!capable(CAP_SYS_ADMIN)) {
        printk(KERN_ERR "my_device: need CAP_SYS_ADMIN to execute ioctl\n");
        return -EPERM;
    }
    // 执行IOCTL命令逻辑...
    return 0;
}

// 更新file_operations，添加ioctl操作
static const struct file_operations my_fops = {
    .owner = THIS_MODULE,
    .open = my_device_open,
    .unlocked_ioctl = my_device_ioctl, // 绑定IOCTL函数
};

普通用户可通过setcap命令为程序添加特定能力，无需赋予root权限：

# 为my_app程序添加CAP_SYS_ADMIN能力
setcap cap_sys_admin+ep /path/to/my_app

3.3 访问控制表（ACL）的扩展权限

对于需要更精细访问控制的场景（如允许特定用户访问设备，而非整个用户组），Linux支持"访问控制表（ACL）"机制。ACL可在设备文件上附加额外的权限规则，例如允许用户alice读写/dev/my_device：

# 查看设备文件当前ACL
getfacl /dev/my_device
# 为用户alice添加读写权限
setfacl -m u:alice:rw /dev/my_device
# 查看修改后的ACL
getfacl /dev/my_device
# 输出示例：
# user::rw-
# user:alice:rw-
# group::r--
# mask::rw-
# other::r--

内核在处理设备文件访问时，会优先检查ACL规则，再 fallback 到传统的uid/gid权限，实现更灵活的访问控制。

四、设备访问限制：从硬件隔离到驱动防护

除权限控制外，Linux还通过硬件隔离、驱动防护机制限制设备访问，防止非法操作破坏硬件或内核。

4.1 硬件级隔离：I/O端口与I/O内存保护

硬件设备的I/O端口（如PCI设备的配置空间）和I/O内存（如显卡的显存）是敏感资源，内核通过request_region（申请I/O端口）和request_mem_region（申请I/O内存）函数确保资源独占，防止多个驱动同时访问：

#include 

#define MY_DEVICE_IO_PORT 0x378 // 并口LPT1的I/O端口
#define MY_DEVICE_IO_SIZE 3    // 端口范围：0x378-0x37A

static int __init my_device_init(void) {
    // 申请I/O端口范围，设备名"my_device"
    if (!request_region(MY_DEVICE_IO_PORT, MY_DEVICE_IO_SIZE, "my_device")) {
        printk(KERN_ERR "my_device: I/O port 0x%x is busy\n", MY_DEVICE_IO_PORT);
        return -EBUSY;
    }
    // 申请成功，后续可通过inb/outb操作端口...
    return 0;
}

// 驱动卸载时释放I/O端口
static void __exit my_device_exit(void) {
    release_region(MY_DEVICE_IO_PORT, MY_DEVICE_IO_SIZE);
}

module_init(my_device_init);
module_exit(my_device_exit);
MODULE_LICENSE("GPL");

若其他驱动尝试申请已被占用的I/O端口，request_region会返回NULL，避免资源冲突导致的硬件异常。

4.2 驱动层访问限制：禁止非法操作

驱动可通过过滤非法操作类型（如禁止对只读设备执行写操作）进一步限制访问。例如，对只读传感器设备，驱动可在write函数中直接返回错误：

// 只读传感器设备的write函数：禁止写入
static ssize_t my_sensor_write(struct file *filp, const char __user *buf, size_t count, loff_t *pos) {
    printk(KERN_ERR "my_sensor: this device is read-only\n");
    return -EINVAL; // 非法操作，返回错误码
}

// 文件操作结构体：绑定read，禁止write
static const struct file_operations sensor_fops = {
    .owner = THIS_MODULE,
    .read = my_sensor_read, // 仅实现read操作
    .write = my_sensor_write, // 写操作返回错误
};

4.3 用户空间访问限制：udev规则与设备隔离

udev作为Linux的设备管理守护进程，可通过规则文件（/etc/udev/rules.d/）动态配置设备文件权限、所有者和符号链接，实现用户空间的访问限制。例如，仅允许video用户组访问摄像头设备：

# 创建udev规则文件：/etc/udev/rules.d/99-camera.rules
SUBSYSTEM=="video4linux", KERNEL=="video[0-9]*", GROUP="video", MODE="0660"

当摄像头设备（属于video4linux子系统）插入时，udev会自动创建/dev/video0等设备文件，设置所属组为video，权限为0660（仅所有者和组有读写权限），普通用户需加入video组才能访问摄像头。

五、安全实践：设备驱动权限配置最佳实践

• 最小权限原则：仅授予进程完成任务必需的权限（如普通用户访问键盘仅需读权限，无需写权限）；
• 避免root默认权限：设备文件默认所有者为root，但应根据场景设置合适的所属组（如磁盘设备所属组为disk）；
• 使用capability替代root：对需要部分特权的程序，通过setcap赋予特定能力，而非直接使用sudo；
• 驱动层双重校验：不仅依赖设备文件权限，还在驱动的open/read/write函数中添加权限校验，防止绕过文件系统权限的攻击；
• 定期审计权限配置：通过ls -l /dev、getfacl检查设备文件权限，及时发现过度开放的配置。