【2021-07-31 更新】【梳理】简明操作系统原理 第十九章 身份认证和访问控制（docx）

配套教材：
Operating Systems: Three Easy Pieces Remzi H. Arpaci-Dusseau Andrea C. Arpaci-Dusseau Peter Reiher
参考书目：
1、计算机操作系统（第4版） 汤小丹 梁红兵 哲凤屏 汤子瀛 编著 西安电子科技大学出版社

在线阅读：
http://pages.cs.wisc.edu/~remzi/OSTEP/
University of Wisconsin Madison 教授 Remzi Arpaci-Dusseau 认为课本应该是免费的。
————————————————————————————————————————
这是专业必修课《操作系统原理》的复习指引。
需要掌握的概念在文档中以蓝色标识，并用可读性更好的字体显示 Linux 命令和代码。代码部分语法高亮。
文档下载地址：
链接：https://pan.baidu.com/s/1VeDysG_z0ApB2wtOFgQTxA
提取码：0000

十九 身份认证和访问控制

在计算机安全领域，我们通常将询问某些事物的实体称为主体（principal）。主体具有安全意义的能够请求对资源的访问权的实体，例如，用户、用户组，以及复杂的软件系统。进程或其它活动的计算实体，代表主体执行请求的，通常被称为代理（agent）。如果请求是为了访问特定的资源，通常将资源称为访问请求的对象（object）。由操作系统创建和管理的用于追踪访问的任何形式的数据称为凭证（credential，凭据）。
如果操作系统还没有产生凭证，表明允许一个代理进程访问特定的对象，操作系统就需要进程主体的身份信息，来确定它的请求是否应被授权。不同的操作系统使用不同类型的主体身份。许多操作系统都记录用户身份，用户一般是指人类（近年来，用户这个概念已经大大扩展）。这意味着：特定人员运行的所有进程，可能都具有相同的身份。另一种常见的身份类型是用户组。还有一种身份类型是进程运行的程序（program）。同一个程序可以被运行多次，每次都会打开一个新的进程。在Android等系统中，可以为特定的程序进行授权。
无论采用何种身份类型，都应当能够将它们与进程关联起来。除了操作系统自己的活动，一切都由特定的进程执行。所以，为进程的每个重要动作核对安全策略，是一定有机会的。但操作系统通常不这样做：一旦一个进程通过身份认证，那么在它剩余的生命周期内，基本都依据这次身份认证的判定了（换句话说，基本不会再重新认证了）。

进程一般是由其它进程来创建的。如果子进程总是继承父进程的身份，那么将身份与进程结合起来固然很简单。但是，操作系统启动时，为了能够正常加载所有组件，必须令最初的进程获得最高权限。这之后创建其它进程时，都继承了这个最高权限的身份，那自然就无法应用已有的安全策略了。
如果进程以用户ID之类的作为安全身份，必须为每个新进程都设置正确的用户ID。在许多系统中，用户总是要通过特定的进程来完成工作，例如shell或窗口管理器。如果你在shell中输入一个命令，或者在窗口系统中双击一个图标，就代表你要求操作系统以你的身份创建一个新进程。
Shell或窗口管理器如何确定自己的身份？这就需要一点点操作系统特权。当用户首次与系统进行交互时，操作系统为该用户创建一个进程。操作系统可以在自己的数据结构，例如进程控制块（PCB），设置新进程属于新加入系统的用户。
那么，如何确定用户的身份？自然是需要在用户登录时提供身份信息了。到此为止，我们已经发现了操作系统的一个新需求：它必须能够向人类用户请求身份，并验证他们声称自己是谁，以便为进程分配正确的身份，从而实现预设的安全策略。

首先，如果一个人根本不是这个系统的授权用户，那么必须要拒绝他的登录请求；其次，如果他是授权用户，那么，他具体是哪一种或者哪一个？
对人类进行身份验证，有三种古典的方法：
·基于他知道的进行身份验证。
·基于他拥有的进行身份验证。
·基于他是谁进行身份验证。
我们说它们是古典的，因为这些手段能够追溯到古希腊和古罗马时期。公元前2世纪，坡利比阿斯（Polybius）记载了古罗马军队如何使用口令（watchwords）区别友军与敌军。在公元2世纪，一个名为Celer的古罗马建筑师为他的一个被交给帝国检察官的奴隶写了一封推荐信（目前仍被保留）。这是基于奴隶拥有什么来进行身份验证。在更远古的圣经的时代，基列人（Gileadite）要求战后的难民说出单词“shibboleth”，因为他们觉得他们的敌人以法莲人（Ephraimite）不能正确发音这个词。这是基于被验证者是谁的身份验证：他的母语是基列方言还是以法莲方言。

你所知道的身份验证一般是使用密码（password）完成的。在计算机安全中，密码拥有一段长而不光彩的历史，起源不晚于1960年代早期的MIT的CTSS系统。密码是仅由被授权的一方知晓的秘密。在尝试登录时，将其输入到计算机，证明自己的身份。这种授权方式的效率取决于几点。首先，假设其他人都不知道密码。并且，假设其他人也不能猜出密码来。当然，输入密码的人本身也必须知道密码。

先不管密码被猜出来的情况。如果其他人知道密码，他们是怎样知道的呢？已经知道密码的人可能不小心泄露出来。所以，知道密码的人越少，这种担心自然就越少。我们真不希望其他人获得授权并进入系统，因此希望不要有任何第三方知道密码。这也蕴含着：用户不能将密码写在纸上，否则，偷到这张纸的人就会得知密码。此外，系统本身也必须知道密码，才能验证身份。这也带来了另一点脆弱性：系统中保存的密码可能泄露出来。第一次已知的存储密码泄露事件发生于1962年。这种泄露直到今天还在不断发生，并且发生的范围大得多。
有趣的是，系统实际上并不知道密码具体是什么。检查密码时，只需要确定用户确实知道密码，而不是密码本身是什么内容。系统可以通过存储密码的哈希（hash，散列）值来实现这一点。当用户输入密码后，将输入做一次哈希，与存储的哈希值比对。如果相同，就意味着用户知道密码。如果没有留心存储的授权信息，导致它们泄露了，那么泄露的也只是哈希。如果将泄露的哈希作为密码输入，那么产生的哈希值几乎不可能与原密码的哈希值一致。
但是，仅仅存储与密码不同的内容是不够的。我们还希望，攻击者不能通过分析存储的哈希，得出密码的一些线索。有一类特殊的哈希算法叫做加密哈希（cryptographic hash），它们使得通过哈希值猜出密码是不可行的。然而很不幸，设计它们非常困难，所以聪明人也不应该随意尝试，而是使用由专家创建的加密哈希算法。现代系统在密码哈希方面需要做的是：使用一种被彻底研究的、没有已知缺陷的加密哈希算法。在编写本文时，SHA-3是美国标准的加密哈希算法，并且是一个好选择。

然后，考虑猜出密码的情形。显然，密码的组合种数随着密码长度指数级增长。一些早期的密码只能使用字母，虽然这让密码更好记也更容易输入，但是也令密码的组合数极大地减少了。现在，设置密码时，一般至少都能接受大小写字母、数字和特殊符号。
虽然能够使用多种字符组合，但是攻击者也清楚，人们一般不会使用这些字符的随机字符串作为密码，而是选择一些名字和熟悉的单词等等，因为它们更容易被记住。攻击者猜测密码时，会在开始猜测随机字符之前，先尝试常用的名字和单词。这种密码猜测称为字典攻击（dictionary attack），而且可以很高效。这里的字典并不是指Webster或者Oxford之类的字典，而是关于单词、名称、有意义的字符串（如“123456”）等等的特殊列表，按概率进行排列。一次有效的字典攻击，可以猜出一个典型网站中90%的密码。
如果你在设计系统时足够醒目，攻击者应当无法通过远程登录过程来运行字典攻击。只要稍加小心，攻击者就无法在五六次左右就能猜出一个用户的密码。并且，更没有理由允许一个远程用户猜测密码15000次还猜不对。所以，在多次输入错误密码后关闭一个账户的访问权。或者在数次密码错误后延长检查密码的时间，就可以防护字典攻击。
如果攻击者获得了密码文件，并已知哈希算法，准备好一个字典和一些算力，他就有可能撞出密码来。攻击者只需要将每种可能的密码都试一次，将它们的哈希存入字典中，就可以根据获得的密码文件中的哈希值找到密码。
有一个很简单的修复方案。在对新密码哈希并存储之前，生成一个大的随机数，将其与密码进行连接，将连接结果哈希并存储。同样也需要存储随机数。当用户提供正确密码时，就需要将用户输入的密码与存储的随机数连接起来，再运行哈希算法。这个随机数称为盐（salt）。这是Robert Morris和Ken Thompson在早期的密码安全论文中引入的概念。
加盐密码极大挫败了字典攻击。如果随机数是32位的，就意味着一种密码生成的哈希最多有232种。虽然说，如果选择糟糕的密码，攻击依然是有可能的，但是攻击的成本已经非常高。任何使用密码的良好系统，都应当注意存储加密哈希并加盐的密码，否则，用户就被置于风险中。

关于密码的使用，还有许多引起麻烦的其它问题，但很多都与操作系统无关，本书不予讨论。在计算机安全社区，当前普遍持有的一种观点是：密码是过去的技术，在当今的环境下已经不再足够安全。但不论如何，密码至少可以作为身份验证的机制之一。这种思想成为多因子