《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等)。