检查 udev 规则中可疑 RUN+ 指令，需扫描 /etc/udev/rules.d/ 下所有 .rules 文件，重点关注数字前缀大、含 custom/hotplug/auto 的文件；用 grep -r "RUN+=" /etc/udev/rules.d/ --include="*.rules" 筛出指令，核查是否含内联执行（如 /bin/sh -c '...'）、非标路径脚本、宽泛匹配或未校验 $env{...} 变量；再通过 udevadm monitor 实时监听事件触发，并结合日志验证实际执行行为。
怎么看 udev 规则里有没有可疑的 RUN+ 指令
udev 规则文件是纯文本，但容易被植入隐蔽执行逻辑。重点检查 /etc/udev/rules.d/ 下所有以 .rules 结尾的文件，尤其是数字前缀较大（如 99-）、名称含 custom、hotplug、auto 的文件。
用以下命令快速筛出所有带 RUN+ 的规则行：
grep -r "RUN+=" /etc/udev/rules.d/ --include="*.rules"
重点关注这些特征：
-
RUN+="/bin/sh -c '...'或RUN+="/usr/bin/python3 -c '...'—— 直接执行内联代码，极可疑 -
RUN+="/path/to/unknown/script.sh"—— 路径不在标准位置（如/usr/local/bin/或/opt/），且脚本不存在或权限异常（如 world-writable） - 匹配条件过于宽泛：比如
SUBSYSTEM=="usb"但没限制ENV{ID_BUS}=="usb"或ENV{ID_FS_TYPE}!=""，可能被任意 USB 设备触发 - 使用
$env{...}引用了未校验的环境变量（如$env{ID_VENDOR}），可能被构造恶意设备名绕过过滤
怎么确认某个规则是否真在执行恶意动作
udev 是事件驱动的，不能只看规则是否存在，得验证它是否被实际触发并执行了什么。分两步做：
第一步：实时监听匹配事件。假设你怀疑某条规则匹配 SUBSYSTEM=="usb"，运行：
udevadm monitor --subsystem-match=usb --property
然后插拔一个普通 U 盘，观察输出中是否有 UDEV 行，以及 EXEC 字段是否出现——有就说明规则已生效。
第二步：检查规则调用的命令是否真在运行。如果规则写了 RUN+="/path/to/malware.sh"，但脚本本身不写日志，可临时替换为：
RUN+="/bin/sh -c 'echo \"$(date): $ACTION $KERNEL\" >> /tmp/udev-debug.log; /path/to/malware.sh"'
注意：/tmp/udev-debug.log 需提前创建并设为 root 可写；若日志没更新，说明规则根本没匹配或被跳过。
为什么有些恶意规则看起来“没生效”却仍在后台作祟
常见误导点是只盯着 ACTION=="add" 或 "remove"，而忽略 "change"。HDMI、DP、甚至某些 USB-C 显示设备插拔时，内核发的是 change 事件，不是 add/remove。攻击者可能故意写：
ACTION=="change", SUBSYSTEM=="drm", RUN+="/tmp/.x"
这种规则不会在 USB 存储插拔时触发，但在显示器热插拔时静默执行，更难关联到异常行为。
另一个盲区是规则依赖父设备匹配。比如写 KERNEL=="sdb" 本意是匹配某块盘，但实际匹配到了 /sys/block/sdb/device 这个父节点，导致规则在设备还在系统里时反复触发。正确做法是加 DEVPATH 或 ENV{ID_SERIAL} 锁定具体设备。
如何安全清理和防御这类规则
不要直接 rm 规则文件后就以为完事——udev 缓存可能未刷新，旧规则仍会响应后续事件。必须组合操作：
- 删掉可疑文件后，立刻运行
udevadm control --reload-rules - 再执行
udevadm trigger --subsystem-match=usb --action=change（或其他对应子系统），强制重放事件，确认无残留输出 - 检查
/dev/.udev/queue.bin（若存在）是否为空，非空说明还有待处理事件 - 对所有
RUN+调用的脚本，用stat -c "%U:%G %a %n" /path/to/script查属主和权限，world-writable 或属主为非 root 的脚本一律禁止执行
真正难防的是那些把 payload 埋进合法规则里的变种——比如在一条正常的 HDMI 自动配置规则末尾，悄悄追加 ; /dev/shm/.p &。人工 review 容易漏，建议用 grep -E "\.sh|\.py|;.*&|&.*;|/dev/shm|/tmp/[^ ]+\.so" /etc/udev/rules.d/*.rules 辅助扫描。
