Web应用不应也不需访问内核，防护核心是阻断从Web层到内核提权的路径：通过运行身份最小化、文件权限隔离、Seccomp-BPF限权、Kernel Lockdown及纵深防御多层拦截。
不能直接限制 Web 应用对系统内核的访问——Web 应用本身就不该、也不需要调用内核接口。所谓“限制内核访问权限”，本质是切断攻击者借由 Web 层漏洞（如远程代码执行、WebShell）向内核提权的路径。重点不在“拦内核调用”，而在“不让攻击者走到能调用内核那一步”。
运行身份最小化：用非特权用户启动服务
Web 应用进程必须以低权限系统用户（如 www-data、nginx 或自定义的 webapp）运行，严禁使用 root 或管理员账户。这能天然阻断绝大多数内核级提权链的起点。
- 在 systemd 服务文件中显式指定
User=和Group=，并禁用Capabilities=（尤其避免CAP_SYS_ADMIN） - Docker 部署时使用
--user 1001:1001，配合USER 1001指令写入 Dockerfile - 验证方式：登录容器或服务器，执行
ps aux | grep your_app，确认 UID 不为 0
文件与目录权限隔离：堵死本地提权跳板
很多内核提权利用依赖读取敏感文件（如 /proc/sys/kernel/unprivileged_userns_clone）、写入可加载模块路径或滥用挂载点。严格管控文件系统权限，可让攻击者即使拿到 WebShell 也寸步难行。
- Web 根目录及上传目录设为
750，属主为运行用户，属组为专用组，禁止 world 可读写 -
/tmp和/var/tmp启用noexec,nosuid,nodev挂载选项（通过/etc/fstab或 systemd mount unit） - 禁用
/proc下危险接口：例如通过 sysctl 关闭kernel.unprivileged_userns_clone=0（Linux 5.12+）
运行时约束：用内核机制主动限权
现代 Linux 提供了多层运行时防护能力，无需修改应用代码，即可从内核层面收窄攻击面。
- 启用 Seccomp-BPF 过滤器：只允许应用必需的系统调用（如
read、write、socket），明确禁止open_by_handle_at、init_module、ptrace等高危调用 - 容器场景下，在
docker run中添加--security-opt seccomp=webapp.json；K8s 则通过 PodSecurityPolicy 或 SecurityContext 配置 - 启用 Kernel Lockdown 模式（
lockdown=confidentiality）：阻止未签名内核模块加载和 /dev/mem 访问，大幅提高内核利用门槛
纵深防御补位：让提权链断在中间环节
即使某一层被绕过，其他控制措施仍应生效。关键在于不依赖单一防护，而是形成协同拦截。
- Web 应用自身禁用危险函数：PHP 设置
disable_functions = system,exec,passthru,shell_exec,proc_open；Node.js 应用避免child_process.execSync等同步执行调用 - 数据库账户仅授予业务所需最小权限，禁用
FILE、LOAD DATA INFILE等可导致文件读写的能力 - 日志审计全覆盖：记录所有 execve 系统调用（通过 auditd 规则
-a always,exit -F arch=b64 -S execve），便于发现异常提权尝试
