sysctl 无法拦截或限制硬链接与软链接的创建和使用，仅提供 fs.protected_hardlinks 和 fs.protected_symlinks 两项保护性限制，需配合挂载选项、capabilities 剥离及 MAC 策略实现全面防护。
sysctl 无法拦截或限制硬链接（hard link）与软链接（symbolic link）的创建与使用，这不是 sysctl 的职责范围，也不在内核网络/内存/文件系统运行时参数的管控范畴内。
硬链接和软链接属于 VFS（虚拟文件系统）层的文件操作行为，由 link(2)、symlink(2) 等系统调用直接处理，其权限控制完全依赖于：
- 文件系统挂载选项（如
noexec,nosuid,nodev） - 进程的用户/组身份与 umask
-
CAP_DAC_OVERRIDE、CAP_FOWNER等 Linux capabilities - SELinux/AppArmor 等 MAC（强制访问控制）策略
- 文件系统本身的特性（如 ext4 不允许对目录建硬链接；XFS 支持但受权限约束）
⚠️ 关键事实：
-
sysctl不提供任何参数用于禁止ln命令、禁用link()系统调用、或全局拦截 symlink 解析 -
/proc/sys/fs/下仅有少量与链接相关的参数，例如：-
fs.protected_hardlinks = 1（默认启用）→ 阻止非特权用户对其他用户文件创建硬链接（防提权绕过） -
fs.protected_symlinks = 1（默认启用）→ 阻止非特权用户在粘滞位目录（如/tmp）中通过 symlink 指向其他用户文件进行 open()（防chown + symlink提权）
这两个参数是唯一相关且有效的内核防护机制，但它们属于“保护性限制”，不是“全面拦截”。
-
✅ 正确做法（分层加固）：
1. 启用并确认内核链接保护机制
这两个参数必须为 1（现代发行版通常默认开启，但仍需验证）：
sysctl fs.protected_hardlinks sysctl fs.protected_symlinks
若未启用，临时开启：
sudo sysctl -w fs.protected_hardlinks=1 sudo sysctl -w fs.protected_symlinks=1
永久生效（推荐方式）：
echo 'fs.protected_hardlinks = 1' | sudo tee /etc/sysctl.d/99-link-protection.conf echo 'fs.protected_symlinks = 1' | sudo tee -a /etc/sysctl.d/99-link-protection.conf sudo sysctl --system
✅ 效果：
protected_hardlinks=1：阻止普通用户对不属于自己的可写文件（尤其是/tmp中的 world-writable 文件）创建硬链接，从而防止通过chown+unlink修改属主后覆写关键文件（如/etc/passwd备份）。protected_symlinks=1：要求 symlink 访问时满足「目标路径与当前进程具有相同 uid/gid」或「目标不在粘滞位目录中」，大幅增加symlink类提权利用难度。
2. 文件系统挂载加固（非 sysctl，但必须做）
在 /etc/fstab 中为敏感分区添加安全选项：
/dev/sda1 /tmp ext4 defaults,noexec,nosuid,nodev 0 2 /dev/sda2 /var/tmp ext4 defaults,noexec,nosuid,nodev 0 2
然后重新挂载：
sudo mount -o remount /tmp
3. 限制危险 capability（容器/服务级）
避免进程拥有 CAP_FOWNER 或 CAP_DAC_OVERRIDE，尤其对低权限服务：
# systemd service 示例 CapabilityBoundingSet=~CAP_FOWNER ~CAP_DAC_OVERRIDE NoNewPrivileges=yes
4. 使用 MAC 策略（强推荐生产环境）
- SELinux：启用
deny_ptrace、secure_mode_policyload，并为关键服务定义严格域（如httpd_t不允许create_link）。 - AppArmor：明确拒绝
link,symlink,readlink权限（除必要路径外）。
❌ 无效/误导操作（请勿尝试）：
-
sysctl net.ipv4.conf.all.accept_redirects=0→ 无关网络重定向，对链接无影响 -
sysctl fs.suid_dumpable=0→ 控制 core dump 行为，不防链接提权 - 修改
kernel.modules_disabled=1→ 禁用模块加载，与链接无关 - 试图用
net.core.somaxconn或vm.swappiness“间接影响” → 完全无逻辑关联
总结：
防范硬链接/软链接提权后门，核心是启用 fs.protected_hardlinks 和 fs.protected_symlinks，配合挂载选项、capability 剥离与 MAC 策略。sysctl 在此场景下仅提供这两项基础防护，其余必须靠文件系统、权限模型与安全框架协同完成。
