第 4 章 认证和访问控制

下面是一些 PAM 和 NSS 访问的重要配置文件。

密码选择的限制是通过 PAM 模块 pam_unix(8) 和 pam_cracklib(8) 来实现的。它们可以通过各自的参数进行配置。

	提示
	PAM 模块在文件名中使用后缀 “.so”。

现代的集中式系统管理可以使用集中式的轻量目录访问协议（LDAP）服务器进行部署，从而通过网络管理许多类 Unix 和 非类 Unix 系统。轻量目录访问协议的开源实现是 OpenLDAP 软件。

LDAP 服务器使用带有 PAM 和 NSS 的libpam-ldap 和 libnss-ldap 软件包为 Debian 系统提供账号信息。需要一些动作来启用 LDAP（我没有使用过这个设置，并且下面的信息纯粹是第二手的信息。请在这种前提下阅读下列内容。）。

参见由 libpam-doc 软件包提供的 pam_ldap.conf(5) 中的文档和 “/usr/share/doc/libpam-doc/html/”，以及 glibc-doc 软件包提供的 “info libc 'Name Service Switch'”。

类似地，你可以使用其它方法来设置另一种集中式的系统。

这是在旧的 “info su” 底部 Richard M. Stallman 所说的一句名言。别担心：Debian 系统中当前的 su 命令使用了 PAM，这样当在 “/etc/pam.d/su” 中启用了带有 “pam_wheel.so” 的行后，就能够限制非 wheel 组的用户 su 到 root 组的能力。

# here are the per-package modules (the "Primary" block)
password	requisite			pam_cracklib.so retry=3 minlen=8 difok=3
password	[success=1 default=ignore]	pam_unix.so obscure use_authtok try_first_pass yescrypt
# here's the fallback if no module succeeds
password	requisite			pam_deny.so
# prime the stack with a positive return value if there isn't one already;
# this avoids us returning an error just because nothing sets a success code
# since the modules above will each just jump around
password	required			pam_permit.so
# and here are more per-package modules (the "Additional" block)
password	optional	pam_gnome_keyring.so
# end of pam-auth-update config

许多流行的传输层服务都使用纯文本来传输包括密码验证信息在内的各类消息。使用纯文本在公网上传输密码是很糟糕的做法，因为这样传输的密码很容易在网上被他人截获。为了确保整个沟通过程，包括密码信息在内都使用加密传输来确保安全，您可以在“传输层安全（Transport Layer Security，TLS）”协议或者其前身，“安全套接字层（Secure Sockets Layer，SSL）”协议之上运行这些服务。

加密消耗 CPU 时间。作为对 CPU 有益的替代方案，你可以保持使用纯文本通讯，仅仅使用安全认证协议加密密码，比如说：POP 使用"Authenticated Post Office Protocol" (APOP)，SMTP 和 IMAP 使用 "Challenge-Response Authentication Mechanism MD5" (CRAM-MD5)。（你的邮件客户端通过互联网上你的邮件服务器发送邮件时，最近流行使用新的递交端口 587 来代替传统的 SMTP 端口 25，这样可以避免在使用 CRAM-MD5 认证自己时，网络提供商阻塞 25 端口。）

安全 Shell (SSH) 程序使用安全认证来提供不安全网络上两个不可信任主机之间的安全加密通讯。它由 OpenSSH 客户端, ssh(1), 和 OpenSSH 后台守护进程（daemon）, sshd(8)组成.SSH 使用端口转发特性，可以给 POP 和 X 之类的不安全的协议通讯建立隧道，使其可以在互联网上安全传输。

客户端可以使用如下方式来认证自己：基于主机的认证、公钥认证、质疑应答认证、密码认证。使用公钥认证，可以实现远程免密码登录。参见 第 6.3 节 “服务器远程访问和工具 (SSH)”.

即使你运行 Secure Shell (SSH) 和 Point-to-point tunneling protocol (PPTP) 这样的安全服务，在互联网上，仍然有机会使用野蛮暴力猜测密码攻击进入。 使用防火墙策略 (参见 第 5.7 节 “Netfilter 网络过滤框架”)，并和下面的安全工具一起，可以提升安全形势。

为阻止人们使用 root 权限访问你的机器，你需要做下面的操作。

• 阻止对硬盘的物理访问

• 锁住 UEFI/ BIOS 来阻止从可移动介质启动

• 为 GRUB 交互式会话设置密码

• 锁住 GRUB 菜单，禁止编辑

如果可以物理访问硬盘，则可以使用下面的步骤，相对简单的重置密码。

1. 将硬盘拿到一个可以设置 UEFI/BIOS 从 CD 启动的电脑。

2. 使用紧急介质启动系统（Debian 启动磁盘, Knoppix CD, GRUB CD, …）。

3. 用读写访问挂载根分区。

4. 编辑根分区的"/etc/passwd"文件，使 root 账户条目的第二段为空。

对于 grub-rescue-pc ，即使用紧急介质启动的电脑，如果有编辑 GRUB 菜单条目 (参见 第 3.1.2 节 “第二阶段：引载加载程序”) 的权限，在启动时，使用下面的步骤更加简单。

系统的 root shell 现在可以无密码访问了。

为避免这些相关问题，仅有的理论上的软件解决方案是使用 dm-crypt 和 initramfs (参见 第 9.9 节 “数据加密提示”)加密 root 分区(或 "/etc" 分区) 。这样的话，你总是需要密码来启动系统。

访问控制列表 ACL 是在 第 1.2.3 节 “文件系统权限” 里面解释的普通权限的一个超集。

在现代桌面环境中，你会遇到 ACL 行为。比如，当一个已经格式化的 USB 存储设备自动挂载到 "/media/penguin/USBSTICK"，一个普通用户 penguin 能够执行：

 $ cd /media/penguin
 $ ls -la
total 16
drwxr-x---+ 1 root    root    16 Jan 17 22:55 .
drwxr-xr-x  1 root    root    28 Sep 17 19:03 ..
drwxr-xr-x  1 penguin penguin 18 Jan  6 07:05 USBSTICK

在第 11 列的 "+" 表示 ACL 在使用。如果没有 ACL，一个普通用户 penguin 应该不能够像这样列出目录内容，因为 penguin 不在 root 组。你能够按如下方式查看 ACL：

 $ getfacl .
# file: .
# owner: root
# group: root
user::rwx
user:penguin:r-x
group::---
mask::r-x
other::---

这里：

更多信息参见 "POSIX Access Control Lists on Linux"、acl(5)、 getfacl(1) 和 setfacl。

sudo(8) 程序是为了使一个系统管理员可以给用户受限的 root 权限并记录 root 活动而设计的。sudo 只需要一个普通用户的密码。安装 sudo 软件包并通过设置 “/etc/sudoers” 中的选项来使用它。参见 “/usr/share/doc/sudo/examples/sudoers” 和 第 1.1.12 节 “sudo 配置” 中的配置示例。

我将 sudo 用于单用户系统（参见 第 1.1.12 节 “sudo 配置”）是为了防止自己可能做出的愚蠢行为。就我个人而言，我认为使用 sudo 会比使用 root 账号操作系统来得好。例如，下列命令将 “some_file” 的拥有者改变为 “my_name”。

$ sudo chown my_name some_file

当然如果你知道 root 密码（比如自行安装 Debian 的用户所做的），任何用户账号都可以使用 “su -c” 让任何命令以 root 运行。

PolicyKit 是在类 Unix 操作系统中控制整个系统权限的一个操作系统组件。

较新的 GUI 图形界面程序设计时便考虑到了不作为特权进程来运行。它们通过 PolicyKit 来和特权进程通信，从而执行管理操作。

在 Debian 系统中，PolicyKit 限制了属于 sudo 组的用户账号的这种操作。

参见 polkit(8)。

对系统安全而言，尽可能的禁用服务程序，是一个好的主意。网络服务是危险的。有不使用的服务，不管是直接由后台守护进程（daemon）激活，还是通过super-server 程序激活，都被认为是安全风险。

许多程序,比如说 sshd(8), 使用基于 PAM 的访问控制。也还有许多方式来限制访问一些服务端的程序。

参见 第 3.5 节 “系统管理”、第 4.5.1 节 “PAM 和 NSS 访问的配置文件” 和 第 5.7 节 “Netfilter 网络过滤框架”。

Linux 内核已经发展和支持在传统的 UNIX 实现里面没有的安全特征。

Linux 支持 扩展属性，扩展了传统的 UNIX 属性 (参见 xattr(7))。

Linux 把传统的超级用户相关的特权分开到不同的单元，被称为 capabilities(7)，它能够独立的启用和禁用。从 2.2 版本内核开始，Capabilities 是一个线程独立的属性。

Linux Security Module (LSM) 安全模块框架 提供了一个多方面的安全检查机制，和新的内核扩展关联。例如：

这些扩展紧缩的权力模型比普通的类 Unix 安全模型策略更加严格，甚至 root 的权力也被限制。建议你阅读 kernel.org 上的 Linux 安全模块（LSM）框架文档。

Linux 的 namespaces 封装了一个全局系统资源到一个抽象的概念，全局系统资源在 namespace 内对进程可见，并且 namespace 有它们自己的全局资源隔离实例。 对其它进程全局资源的可见性的改变是，同一个 namespace 的成员可见，但是对非同一个 namespace 的其它进程不可见。从内核 5.6 版本起，有 8 种 namespaces (参见 namespaces(7), unshare(1), nsenter(1))。

在 Debian 11 Bullseye (2021) 中, Debian 使用 unified cgroup hierarchy（统一 cgroup 层级架构） (亦称为 cgroups-v2)。

namespaces 同 cgroups 一起来隔离它们的进程，允许资源控制的使用示例是：

这些功能不能够通过 第 4.1 节 “一般的 Unix 认证” 实现。这些高级话题大部分超出了本介绍文档的范围。