《UNIX/Linux系统管理技术手册-读书笔记-第三章

1. 标准UNIX访问控制模型

1.1 核心原则

原则 说明
决策依据 执行操作的用户身份组成员关系
对象属主 每个文件/进程都有属主,属主拥有广泛(非无限)控制权
创建者属主 你创建的对象属于你
root特权 root(UID=0)可视为所有对象的属主,可执行所有敏感操作

1.2 文件系统访问控制

概念 说明 能做什么
属主+属组 每个文件有UID属主和GID属组 控制谁可以读/写/执行文件
权限位 r/w/x 分别对应读/写/执行 ls -l查看权限,chmod修改
UID/GID映射 内核用数字ID,/etc/passwd和/etc/group映射为名称 管理用户和组
/etc/group 传统组定义文件,现多用LDAP等网络数据库 集中管理组成员关系

实操命令

1
2
3
ls -l ~garth/todo
# -rw-r----- 1 garth staff 1259 May 29 19:55 /Users/garth/todo
# 属主garth可读写,staff组成员可读

1.3 进程所有权

概念 说明
real UID/GID 用于记账(已较少使用)
effective UID/GID 决定访问权限(关键)
saved UID/GID 保留以备切换回特权模式
filesystem UID NFS相关,通常=effective UID

普通情况下real=effective,特权程序(setuid)会改变effective。

1.4 root账户(超级用户)

特征 说明
决定性特征 UID=0(不是用户名)
特权操作 创建设备文件、设置系统时钟、提高优先级、配置网络、打开<1024端口、关闭系统等
权限传递 root进程可变更自身UID/GID(如login程序验证后降权为普通用户)

不要创建其他UID=0的账户,不要修改root用户名——会破坏安全并造成困惑。

1.5 setuid和setgid

概念 说明 能做什么
setuid位 执行时进程effective UID变为文件属主的UID 普通用户可临时提权执行特权操作(如passwd修改密码)
setgid位 执行时进程effective GID变为文件属组的GID 类似setuid,但针对组权限
风险 setuid程序是安全漏洞高发区 最小化setuid程序数量,不自制setuid程序
nosuid挂载选项 禁止文件系统上的setuid/setgid程序执行 用于用户主目录或不可信来源的挂载点

2. root账户管理最佳实践

2.1 不要直接以root登录

问题 后果
无操作记录 出问题无法回溯
无主体标识 多人共用root无法区分谁做了什么
安全风险 暴露root shell时间越长越危险

推荐做法:禁用root的终端/网络登录。

2.2 su:替换用户身份

用法 说明
su(无参数) 提示输入root密码,启动root shell
su - username 切换至其他用户,生成登录shell
日志记录 记录谁在何时切换为root
搜索路径风险 养成输入完整路径 /bin/su 的习惯,避免被恶意程序劫持
wheel组 多数系统要求是wheel组成员才能用su

su 基本被 sudo 替代,仅作应急备用。

2.3 sudo:受限版su(核心工具)

特性 说明
功能 以root或其他用户身份执行命令
配置文件 /etc/sudoers(用visudo编辑,防止语法错误)
认证超时 默认5分钟内无需重复输入密码
日志记录 通过syslog记录谁、在哪台主机、在哪个目录、运行了什么命令

sudoers典型配置示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
# 别名定义
User_Alias ADMINS = alice, bob, charles
Host_Alias CS = trigger, anchor, piper
Cmnd_Alias DUMP = /sbin/dump, /sbin/restore

# 权限规则(匹配规则:使用最后匹配的一条)
ADMINS ALL = (ALL) ALL                     # alice等可在任何主机以任何身份执行任何命令
%wheel ALL = (ALL) ALL                     # wheel组成员同样
mark, ed PHYSICS = ALL                     # mark/ed在PHYSICS主机组可执行所有命令
herb CS = /usr/sbin/tcpdump                # herb在CS主机可执行tcpdump
lynda ALL = (ALL) ALL, !SHELLS             # 排除shell(注:可绕过)

sudo优点

  • ✅ 命令日志提升审计能力
  • ✅ 细粒度授权(无需给完整root)
  • ✅ 回收权限无需改root密码
  • ✅ 单文件控制全网访问
  • ✅ 比su更快

sudo缺点/风险

  • ❌ sudo用户的个人账户安全=root安全(扩散攻击面)
  • ❌ 日志可被绕过(如sudo sh
  • ❌ 严格限制“除XX之外的所有命令”难以真正实现

实用配置要点

配置项 说明
Defaults env_keep += "SSH_AUTH_SOCK" 保留SSH密钥转发环境变量
Defaults env_keep += "DISPLAY" 保留X11转发
Defaults requiretty 要求有控制终端(部分发行版默认开启,建议关闭以便无值守运行)
NOPASSWD 允许无密码执行(⚠️ 谨慎使用,仅限特定命令)

站点级sudoers分发

  • 使用主sudoers文件(通过scp/cron分发)统一管理
  • 在应用前用 visudo -c -f newsudoers 验证格式
  • 用IP地址匹配而非主机名(云环境主机名不可靠)

2.4 禁用root账户(高级实践)

方法 说明
passwd -l root 在加密密码前加!锁定账户
设置密码为*! 任何密码哈希都无法匹配
效果 root无法登录(包括控制台),su无法使用,但sudo正常工作
推荐场景 已全面部署sudo的组织;物理服务器保留root密码作紧急备用
Ubuntu 默认锁定root,所有管理通过sudo

2.5 系统伪账户

账户 UID范围 说明
bin, daemon <10 拥有非root文件/进程,降低root风险
mysql, postgres 10~100 数据库服务专用账户
nobody 通常65534 NFS映射远程root(不应拥有任何文件)
配置 密码设为*,shell设为/bin/false/bin/nologin 防止登录

3. 标准模型扩展

3.1 标准模型的缺点

缺陷 说明
root单点故障 一个账户毁所有
setuid安全风险 每个setuid程序都是攻击目标
网络认证弱 无法保证远程身份真实性
组管理特权化 普通用户不能自建组
硬编码规则 修改行为需要重新编译源码
审计缺失 难跟踪谁做了什么

3.2 PAM:插接式认证模块

概念 说明 能做什么
PAM 认证框架(非具体方法) 将认证从程序中解耦,支持密码、生物识别、两步认证、网络身份系统等
工作机制 程序调用PAM → PAM调用管理员配置的认证库 灵活更换认证方式,无需改程序
定位 认证技术,非访问控制 解决“怎么证明你是X”,而非“X能否做Y”

3.3 Kerberos:网络加密认证

概念 说明
定位 具体的认证方法(vs PAM是框架)
原理 可信第三方(KDC)发放加密凭证,服务间凭凭证认证
关系 PAM可调用Kerberos(PAM框架+Kerberos实现)
应用 Windows Active Directory标准认证系统

(Kerberos配置详见17.3节)

3.4 文件系统ACL(访问控制列表)

概念 说明 能做什么
ACL 传统“用户/组/其他人”模型的一般化 一次性为多个用户/组设置不同权限
支持前提 文件系统必须明确支持ACL(主流FS均支持) 需要确认挂载选项启用ACL
两种标准 POSIX ACL草案(广泛但非正式标准)、NFSv4 ACL(类似Windows) 详见5.6节

3.5 Linux能力系统(Capabilities)

概念 说明 能做什么
能力 将root权限划分为约30种独立权限 进程只获得必需的能力,不必拥有完整root
典型能力 CAP_NET_BIND_SERVICE(绑定<1024端口) 守护进程可以非root运行但绑定特权端口
实际应用 较少直接使用,被AppArmor、Docker等高层系统利用 容器化安全的基础技术

查看所有能力:man capabilities

3.6 Linux名字空间(Namespaces)

概念 说明 能做什么
名字空间 将进程隔离在层次化分区中,只能看到部分系统资源 实现进程级别的隔离
访问控制效果 子空间中不可见的对象→视为不存在 子空间内root也无法危害外部
应用 Docker容器化技术的核心基础之一 容器隔离、轻量级虚拟化

4. 现代访问控制(MAC系统)

4.1 背景:LSM(Linux Security Module)API

知识点 说明
LSM 内核级API,允许访问控制系统以可装载内核模块形式接入
原因 2001年NSA提议纳入SELinux,内核维护者拒绝,开发LSM作为折中
约束 多个模块同时启用时,所有模块必须一致许可才能执行操作
现实 目前Linux只能选用一个LSM附加模块

主流LSM模块:SELinux、AppArmor、Smack、TOMOYO、Yama

4.2 强制访问控制(MAC)vs 自主访问控制(DAC)

对比 DAC(标准UNIX) MAC(SELinux/AppArmor等)
权限设置者 对象属主自行设置 管理员制定策略,覆盖用户设置
风险 用户可能误设权限 管理员策略强制保障(如“主目录仅属主可访问”)
典型场景 通用系统 政府多级安全、服务保障(守护进程隔离)

MAC核心价值:最小化权限原则——即使软件有缺陷,只能破坏其所需的最小资源范围。

4.3 SELinux:安全增强型Linux

特性 说明
来源 美国国家安全局(NSA)产品
定位 大包大揽:同时实现MAC+RBAC所有特性
复杂度 以难以管理和排错“闻名”
支持发行版 RedHat/CentOS(默认启用)、Fedora;Debian/SUSE有限支持;Ubuntu已转向AppArmor
策略类型 targeted(保护特定守护进程)、strict(全系统)、mls(多级安全)

SELinux配置/etc/selinux/config):

1
2
SELINUX=enforcing        # enforcing | permissive | disabled
SELINUXTYPE=targeted     # 策略数据库名称
模式 效果
enforcing 应用策略,禁止违规
permissive 允许违规但记录日志(用于调试和策略编写)
disabled 完全关闭SELinux

实用工具

工具 功能
audit2allow 从违规日志自动构建策略定义(从permissive模式日志生成策略)
SELinux Policy Editor 图形化策略编辑器(简化策略编写)

本章观点:SELinux弊大于利——复杂性导致安全漏洞(管理员理解不足+攻击者研究深入)。推荐仅在有强制合规要求的环境(政府/金融/医疗)使用。

4.4 AppArmor

特性 说明
开发者 Canonical(Ubuntu发行商)
支持发行版 Ubuntu(默认启用)、Debian、SUSE
定位 服务保障(service securement):限制特定守护进程,非面向用户
配置路径 /etc/apparmor.d/
配置风格 基于文件路径(易读性好,但无法识别硬链接)

AppArmor配置示例(cups-browsed守护进程):

/usr/sbin/cups-browsed {
    include <abstractions/base>
    include <abstractions/nameservice>
    /etc/cups/cups-browsed.conf r,
    /var/cache/cups/* rw,
    /tmp/** rw,
    include <local/usr.sbin.cups-browsed>
}

路径模式:**匹配多级子路径,{var/;}表示可选var前缀。

AppArmor vs SELinux

对比 SELinux AppArmor
配置复杂度 极高 相对简单
标识方式 安全上下文(inode级别) 文件路径
设计哲学 全功能MAC 专注于服务保障
排错难度 困难 相对容易

5. 本章核心命令速查表

命令/文件 用途
ls -l 查看文件权限和属主/属组
chmod 修改文件权限(详见第5章)
su 替换用户身份(建议用sudo替代)
sudo 受限方式执行特权命令
visudo 安全编辑/etc/sudoers(语法验证
passwd -l root 锁定root账户
sudo -u operator /sbin/dump 以operator身份执行命令
sudo -l 列出当前用户可执行的sudo命令
sudo -k 强制重置sudo超时
getcap /usr/bin/ping 查看文件的能力位
setcap cap_net_raw+ep /usr/bin/ping 设置文件能力
systemctl status apparmor 查看AppArmor状态(Ubuntu)
getenforce / setenforce 查看/设置SELinux模式(RedHat)
journalctl -t setroubleshoot 查看SELinux违规日志
audit2allow -a 从日志生成SELinux策略
/etc/selinux/config SELinux主配置文件
/etc/apparmor.d/ AppArmor策略目录
/etc/sudoers sudo主配置文件
/etc/group 传统组定义文件

6. 本章要点总结

层面 核心要点
标准模型 UID/GID驱动,root万能,setuid是提权的主要机制(也是风险源)
root管理 ❌ 避免直接root登录;✅ 使用sudo + 日志;🔒 可禁用root密码
sudo核心 配置/etc/sudoers,用visudo编辑,站点级统一分发
扩展技术 PAM(认证框架)、Kerberos(网络认证)、ACL(多用户权限)、Capabilities(细粒度root)、Namespaces(容器隔离)
MAC系统 SELinux(功能强大但极复杂,RedHat默认)、AppArmor(服务保障,Ubuntu默认)
选择建议 通用场景用标准模型+sudo即可;有强制合规要求再考虑MAC;从permissive日志模式开始调试

DBA视角补充

  • 数据库服务(MySQL/PostgreSQL/Oracle)通常以专用伪账户运行(如mysql),需确保其数据目录权限正确;
  • sudo可用于授权DBA执行特定管理命令(如systemctl restart postgresql),而无需开放完整root;
  • SELinux/AppArmor策略可能阻止数据库访问其数据文件或端口,排查服务启动失败时记得检查MAC日志;
  • setuid程序极少用于数据库场景,更多出现在系统基础命令(passwd、ping等)。