selinux不拦截系统调用链路，而是基于安全上下文标签与策略规则在lsm钩子点对每次操作独立裁决；其防护效果源于进程域限制、资源类型隔离、禁止跨域提权及能力约束等静态策略设计。

SELinux 拒绝非特权用户执行特定系统调用，通常不会直接报“Permission denied”，而是表现为命令静默失败、服务启动卡住（如 status=203/EXEC）、或应用在调用 open、connect、execve、ioctl 等系统调用时被拦截。这类问题本质是 SELinux 策略未授权该用户上下文（subject）对目标资源（object）执行对应操作（permission），需结合审计日志精准定位，而非靠猜测。

确认 SELinux 是否为根源

别跳过这步——很多“权限拒绝”实际与 SELinux 无关：

• 运行 getenforce：若输出 Enforcing，说明策略正在生效；若为 Permissive 或 Disabled，可排除 SELinux
• 临时切换到宽容模式验证：sudo setenforce 0，然后立刻重试触发失败的操作；若问题消失，基本锁定 SELinux
• 立即切回强制模式：sudo setenforce 1，避免审计日志丢失或安全策略失效

抓取并解读 AVC 拒绝日志

SELinux 的拒绝行为统一记录在内核审计日志中（/var/log/audit/audit.log），不是 journalctl 或 /var/log/messages 默认显示的内容：

Browser Setup (No-Root Linux)

在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...

下载

• 查最近的拒绝事件：sudo ausearch -m avc -ts recent
• 按进程名过滤（例如排查 curl 被拦）：sudo ausearch -m avc -c curl
• 用 audit2why 直译拒绝原因：sudo ausearch -m avc -ts recent | audit2why —— 它会告诉你缺哪条 allow 规则，并提示是否可用 restorecon 或 setsebool 修复
• 生成可读报告（需已装 setroubleshoot）：sudo sealert -a /var/log/audit/audit.log

聚焦三类高频拦截点

非特权用户（如普通用户、www-data、nginx、redis 等服务账户）被拒，90% 集中在这三类：

• 文件/脚本上下文错配：比如用户从 /home/alice/bin 移动脚本到 /usr/local/bin/mytool，但没重标上下文，仍带 user_home_t，而 bin_t 才允许被非 root 用户执行 → 修复：sudo semanage fcontext -a -t bin_t "/usr/local/bin/mytool"; sudo restorecon -v /usr/local/bin/mytool
• 布尔值未开启：某些系统调用需显式启用（如普通用户调用 ptrace 调试、访问网络、读取用户家目录）→ 查开关：getsebool -a | grep -E "(ptrace|network|home)"；开布尔值：sudo setsebool -P user_ptrace on
• 端口或设备类型不匹配：用户程序尝试绑定非标准端口（如 8081）、访问 /dev/snd 声卡设备，但对应端口/设备未标记为该用户域允许的类型 → 查当前规则：semanage port -l | grep http_port_t；加端口：sudo semanage port -a -t http_port_t -p tcp 8081

避免误操作：不推荐直接关 SELinux 或盲目用 audit2allow

永久禁用 SELinux（setenforce 0 + 修改 /etc/selinux/config）等于放弃关键防护层；而 audit2allow -M mypolicy 自动生成策略虽快，但极易过度授权（比如放行所有 execmem，埋下漏洞）。正确做法是：

• 先用 restorecon 修复标签，这是最安全、最标准的第一响应
• 优先用 setsebool 启用已有策略开关，比自定义策略更可控
• 仅当确认是新业务场景且无现成布尔值时，才在测试环境审慎使用 audit2allow，并手动精简生成的 .te 文件