12.8.1 Keepalived进程与配置文件权限控制

在Keepalived高可用体系中，进程与配置文件的权限控制是最基础且最关键的防线。本节围绕最小权限原则，给出进程降权、配置文件权限、脚本安全与系统级防护的可执行方案，并配套示例、排错与练习。

原理草图：进程权限边界与配置保护

1. 进程运行用户与权限隔离（含示例）
- Keepalived通常以root启动以操作VIP，但可对脚本和子进程严格降权与授权。
- 创建专用用户与组，并约束脚本执行权限。

# 1) 创建专用用户与组
groupadd -r keepalived
useradd -r -g keepalived -s /sbin/nologin keepalived

# 2) 检查当前运行用户
ps -ef | grep keepalived | grep -v grep

# 3) keepalived.conf 关键安全参数示例
cat >/etc/keepalived/keepalived.conf <<'EOF'
global_defs {
    router_id LVS_01
    # 0: 禁止脚本执行; 1: 允许; 2: 允许并要求脚本权限安全
    script_security 2
    # 启用脚本执行用户（需要 systemd 配合）
    # 注意：部分版本不支持 setuid，此处演示结合 sudoers
}

vrrp_script chk_nginx {
    script "/etc/keepalived/scripts/chk_nginx.sh"
    interval 5
    timeout 2
    fall 2
    rise 1
    user keepalived
}

vrrp_instance VI_1 {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
        10.0.0.100/24 dev eth0
    }
    track_script {
        chk_nginx
    }
}
EOF

# 4) 检查配置语法（执行后返回 0 为正常）
/usr/sbin/keepalived -t -f /etc/keepalived/keepalived.conf; echo $?

命令解释：
- script_security 2：要求脚本权限安全，否则拒绝执行。
- user keepalived：脚本执行用户（需版本支持与系统安全策略配合）。
- -t：配置测试模式，验证语法。

2. 配置文件权限与完整性保护（含示例）
- keepalived.conf仅root可写，脚本目录仅运维组可读/执行。
- 关键配置启用不可变标记，避免误改。

# 配置文件与目录权限
chown root:keepalived /etc/keepalived/keepalived.conf
chmod 640 /etc/keepalived/keepalived.conf
chmod 750 /etc/keepalived
mkdir -p /etc/keepalived/scripts
chown root:keepalived /etc/keepalived/scripts
chmod 750 /etc/keepalived/scripts

# 关键脚本权限
cat >/etc/keepalived/scripts/chk_nginx.sh <<'EOF'
#!/bin/bash
# 检查nginx进程是否存在
if pgrep -x nginx >/dev/null; then
  exit 0
else
  exit 1
fi
EOF
chown root:keepalived /etc/keepalived/scripts/chk_nginx.sh
chmod 750 /etc/keepalived/scripts/chk_nginx.sh

# 启用不可变标记（变更前需解除）
chattr +i /etc/keepalived/keepalived.conf
lsattr /etc/keepalived/keepalived.conf

命令解释：
- chmod 640：仅root可写，运维组可读。
- chattr +i：不可变，防止误操作或恶意篡改。

3. systemd进程级安全（含示例）
- 通过systemd限制文件系统与权限扩展，降低攻击面。

# 创建 systemd 覆盖配置
mkdir -p /etc/systemd/system/keepalived.service.d
cat >/etc/systemd/system/keepalived.service.d/security.conf <<'EOF'
[Service]
NoNewPrivileges=true
ProtectSystem=full
ProtectHome=true
PrivateTmp=true
ReadWritePaths=/var/run/ /var/lib/keepalived/
EOF

# 重新加载并重启
systemctl daemon-reload
systemctl restart keepalived
systemctl status keepalived --no-pager

命令解释：
- NoNewPrivileges=true：禁止进程提权。
- ProtectSystem=full：系统目录只读。
- ReadWritePaths：仅允许写入指定目录。

4. 脚本安全与sudo精确授权（含示例）
- 禁止脚本使用通配符与外部输入，命令路径必须为绝对路径。
- 如需权限提升，使用sudoers精确授权。

# /etc/sudoers.d/keepalived 仅授权重启nginx
cat >/etc/sudoers.d/keepalived <<'EOF'
keepalived ALL=(root) NOPASSWD: /usr/bin/systemctl restart nginx
EOF
chmod 440 /etc/sudoers.d/keepalived

# 修改脚本：必要时用sudo执行指定命令
cat >/etc/keepalived/scripts/chk_nginx.sh <<'EOF'
#!/bin/bash
if /usr/bin/pgrep -x nginx >/dev/null; then
  exit 0
else
  /usr/bin/sudo /usr/bin/systemctl restart nginx
  exit 1
fi
EOF
chmod 750 /etc/keepalived/scripts/chk_nginx.sh

5. 排错指南（含命令）
- 症状：脚本不执行 / 权限被拒绝
- 排查命令：

journalctl -u keepalived -n 200 --no-pager
/usr/sbin/keepalived -t -f /etc/keepalived/keepalived.conf
ls -l /etc/keepalived/keepalived.conf /etc/keepalived/scripts/chk_nginx.sh

症状：配置变更不生效
排查命令：

# 检查是否有不可变标记
lsattr /etc/keepalived/keepalived.conf
# 若有 i 标记，先解除再修改
chattr -i /etc/keepalived/keepalived.conf

症状：systemd安全限制导致无法写状态文件
排查命令：

# 查看是否因 ProtectSystem 导致写入失败
journalctl -u keepalived | grep -i denied
# 需要时增加可写路径
sed -n '1,120p' /etc/systemd/system/keepalived.service.d/security.conf

6. 安装与启动验证（最小可执行流程）

# 安装
yum install -y keepalived || apt-get install -y keepalived

# 配置后检测
/usr/sbin/keepalived -t -f /etc/keepalived/keepalived.conf

# 启动与验证
systemctl enable --now keepalived
ip addr show dev eth0 | grep 10.0.0.100

7. 练习与自检
1) 将keepalived.conf权限从644改为640，观察script_security 2是否仍允许脚本执行。
2) 为/etc/keepalived/keepalived.conf加上chattr +i后尝试修改，记录报错信息并恢复。
3) 启用systemd安全策略后，故意删除ReadWritePaths，观察Keepalived日志并修复。
4) 编写一个track_script检测tcp/80存活，要求使用绝对路径与无外部输入。

通过上述进程与配置文件权限控制与验证流程，可显著降低配置被篡改、进程被劫持或权限被提升的风险，为后续VRRP通信安全与系统级加固奠定基础。