核心转储限制不是简单禁用，而是精准控制生成范围、存储路径、内存内容、生命周期和访问权限；需禁止高危进程转储、隔离root权限目录、过滤敏感内存页、自动清理并审计访问。
核心转储限制不是“关掉就安全”，而是精准控制谁、何时、以何种内容、存到哪里、保留多久——目标是让敏感数据不进转储文件，或进了也拿不走、看不懂、留不久。
限制核心转储生成范围，从源头掐断高危进程
不是所有程序都该生成 core。尤其处理密钥、令牌、用户凭证的服务（如 API 网关、认证中间件、数据库代理），应默认禁止转储：
- 对 systemd 托管服务，在 unit 文件中明确设：
[Service] LimitCORE=0
- 避免对 setuid/setgid 程序启用 dump：内核默认
fs.suid_dumpable=0已屏蔽，切勿轻易改为2 - 自研程序可在启动时调用
prctl(PR_SET_DUMPABLE, 0)主动关闭 dump 能力，比依赖全局配置更可靠
✅ 关键点：限制范围比限制大小更重要。一个含密钥的进程生成 1MB core，比十个无敏进程生成 10GB 更危险。
隔离存储路径并收紧权限，防止未授权访问
core 文件一旦落地，就是静态敏感数据载体。必须杜绝“写得到、读得着、删不掉”：
- 创建专用目录，仅 root 可读写：
sudo mkdir -p /var/log/coredumps sudo chown root:root /var/log/coredumps sudo chmod 0700 /var/log/coredumps # 注意：不是 1777（那是给 /tmp 的）
- 配置
kernel.core_pattern指向该目录，并启用进程名+PID+时间戳命名：echo '/var/log/coredumps/core.%e.%p.%t' | sudo tee /proc/sys/kernel/core_pattern
- 永久生效写入
/etc/sysctl.conf：kernel.core_pattern = /var/log/coredumps/core.%e.%p.%t
⚠️ 切记：
/tmp或用户家目录绝对不能作为 core 存放地；1777权限只适用于/tmp类共享目录，core 目录必须是 0700。
过滤内存内容，跳过敏感页而非全量镜像
即使路径安全，原始 core 仍含完整内存快照。可通过内核机制主动剔除高风险区域：
- 启用
coredump_filter，只保留匿名私有内存（通常含业务逻辑变量），跳过文件映射、共享内存、VDSO 等易含密区域：echo 0x33 | sudo tee /proc/sys/kernel/coredump_filter # 0x33 = 0b00110011 → 保留 ANONYMOUS + PRIVATE，排除 SHARED、HUGETLB、DAX 等
- 在程序中对敏感内存块（如密钥缓冲区）调用：
madvise(ptr, len, MADV_DONTDUMP); // glibc ≥2.25 支持
- 编译时减少栈敏感信息：加
-fno-stack-protector -z noexecstack，再用strip --strip-all剥离调试符号
? 补充：
eu-readelf -l core | grep LOAD可验证 core 是否仍含可疑映射段（如[heap]或高地址匿名页）。
自动清理与访问审计，闭环管理生命周期
core 文件不是“生成即完事”，而是需持续管控的敏感资产：
- 设置自动清理策略（如通过
systemd-tmpfiles或定时脚本）：# 删除 7 天前的 core 文件 find /var/log/coredumps -name 'core.*' -mtime +7 -delete
- 开启 auditd 或 inotify 监控 core 目录，记录谁创建、谁读取、谁删除：
sudo auditctl -w /var/log/coredumps/ -p wa -k coredump_access
- 若使用
systemd-coredump，可统一配置/etc/systemd/coredump.conf：MaxUse=512M KeepFree=1G ProcessSizeMax=100M # 单个 core 上限
不复杂但容易忽略
