CS161 Computer Security TextBook | 1. Security Principles 安全原则

Security Principles 安全原则

In this section, we will look at some general principles for secure system design. These ideas also allow us to examine existing systems to understand their security properties. 在本节中，我们将探讨安全系统设计的一些通用原则。这些理念也让我们能够审视现有系统，以了解其安全特性。

In other words, this section contains a list of “things to remember” when thinking about security. 换句话说，本节包含了一份在思考安全问题时“需要记住的事项”清单。

We teach these security principles because they appear frequently in all aspects of the security field. You may hear about them in academic literature and in later parts of this class. 我们教授这些安全原则，因为它们在安全领域的各个方面频繁出现。你可能会在学术文献和本课程的后续部分中见到它们。

1.1. Know your threat model 了解你的威胁模型

A threat model is a model of who your attacker is and what resources they have. Attackers target systems for various reasons, be it money, politics, fun, etc. Some aren’t looking for anything logical—some attackers just want to watch the world burn. 威胁模型是一个关于你的攻击者是谁以及他们拥有哪些资源的模型。攻击者攻击系统的原因多种多样，无论是为了金钱、政治、乐趣等等。有些攻击者并不寻求任何合乎逻辑的目标——有些攻击者只是想看世界毁灭。

Take, for example, your own personal security. Understanding your threat model has to do with understanding who and why might someone attack you; criminals, for example, could attack you for money, teenagers could attack you for laughs (or to win a dare), governments might spy on you to collect intelligence (but you probably are not important enough for that just yet), or intimate partners could spy on you. 以你个人的安全为例。理解你的威胁模型意味着要明白谁可能会攻击你以及为什么；例如，罪犯可能会为了金钱攻击你，青少年可能会为了取乐（或为了完成挑战）攻击你，政府可能会监视你以收集情报（但可能你目前还不足以引起他们的注意），或者亲密伴侣也可能监视你。

Once you understand who your attacker is and what resources they might possess, there are some common assumptions that we take into account for attackers: 一旦你了解攻击者的身份以及他们可能拥有的资源，我们就会对攻击者考虑一些常见假设：

1. The attacker can interact with your systems without anyone noticing, meaning that you might not always be able to detect the attacker tampering with your system before they attack. 攻击者可以在不被察觉的情况下与你的系统交互，这意味着你可能无法在攻击者攻击之前总是检测到他们在篡改你的系统。
2. The attacker has some general information about your system, namely the operating system, any potential software vulnerabilities, etc. 攻击者对你的系统有一些基本信息，即操作系统、任何潜在软件漏洞等。
3. The attacker is persistent and lucky; for example, if an attack is successful 1/1,000,000 times, the attacker will try 1,000,000 times. 攻击者是坚持不懈且幸运的；例如，如果攻击成功率为百万分之一，攻击者会尝试一百万次。
4. The attacker is willing to devote time and resources to the attack (though this may vary; see “Security is Economics” below). 攻击者愿意投入时间和资源进行攻击（尽管这可能有所不同；见下文 “安全是经济问题”）。
5. The attacker can coordinate several complex attacks across various systems. The attacker is not limited to to attacking only a single device, but can attack your entire network at the same time or chain multiple attacks together. 攻击者可以在不同的系统上协调多种复杂的攻击。攻击者不仅限于攻击单个设备，还可以同时攻击整个网络，或将多个攻击串联起来。
6. Every system is a potential target. For example, a casino was once hacked because a fish-tank thermometer was hacked within the network. 每个系统都是潜在的攻击目标。例如，曾经有一家赌场被黑客攻击，因为网络中的鱼缸温度计被入侵了。

Finally, be extremely vigilant when dealing with old code as the assumptions that were originally made might no longer be valid and the threat model might have changed. When the Internet was first created, for example, it was mostly populated by academics who (mostly) trusted one another. As such, several networking protocols made the assumption that all other network participants could be trusted and were not malicious. Today however, the Internet is populated by billions of devices, some of whom are malicious. As a result, many network protocols that were designed a long time ago are now suffering under the strain of attack. 最后，在处理旧代码时要极其警惕，因为最初做出的假设可能不再有效，威胁模型也可能已经改变。例如，互联网刚创建时，主要由（大多）互相信任的学者组成。因此，几个网络协议假设所有其他网络参与者都可以信任且没有恶意。然而，如今互联网由数十亿设备组成，其中一些是恶意的。结果，许多很久以前设计的网络协议现在正承受着攻击的压力。

1.2. Consider Human Factors 考虑人为因素

The key idea here is that security systems must be usable by ordinary people, and therefore must be designed to take into account the role that humans will play. For example, programmers are human and make mistakes. Similarly, users like convenience; if a security system is unusable and not user-friendly, no matter how secure it is, it will go unused. Users will find a way to subvert security systems if it makes their lives easier. 这里的关键思想是，安全系统必须对普通人可用，因此必须设计时要考虑到人类将扮演的角色。例如，程序员是人，会犯错。同样，用户喜欢便利性；如果安全系统不可用且不友好，无论它多么安全，都不会被使用。如果能让生活更方便，用户会想办法规避安全系统。

No matter how secure your system is, it all comes down to people. Social engineering attacks, for example, exploit other people’s trust and access for personal gain. The takeaway here is to consider the tools that are presented to users, and try to make them fool-proof and as user-friendly as possible. 无论你的系统多么安全，最终都取决于人。例如，社会工程攻击就是利用其他人的信任和访问权限谋取私利。这里的启示是，要考虑提供给用户的工具，并尽量使其防骗且用户友好。

For example, suppose your computer pops up with a notification that tells you it needs to restart to “finish installing important updates” while you are in the middle of working on something. If you are like the majority of the user population, you might click “remind me later”, pushing off the update. If the computer is attempting to fix a security patch, the longer the update gets delayed, the longer your computer is vulnerable to an attack. If updates inconvenience the user, they might forego the extra security for convenience. 例如，假设你在处理某项工作时，电脑突然弹出通知，告诉你需要重启以 “完成重要更新”。如果你和大多数用户一样，可能会点击 “稍后提醒我”，从而推迟更新。如果电脑正在尝试修复安全补丁，更新被推迟的时间越长，你的电脑就越容易受到攻击。如果更新给用户带来不便，他们可能会为了方便而放弃额外的安全性。

Another example: the NSA’s cryptographic equipment stores its key material on a small physical token. This token is built in the shape of an ordinary door key. To activate an encryption device, you insert the key into a slot on the device and turn the key. This interface is intuitively understandable, even for 18-year-old soldiers out in the field with minimal training in cryptography. 另一个例子：美国国家安全局（NSA）的加密设备将其密钥材料存储在一个小巧的物理令牌上。这个令牌做成普通门钥匙的形状。要激活加密设备，你需要将钥匙插入设备上的插槽并转动钥匙。这种界面直观易懂，即使是那些在野外服役、几乎没有密码学训练的 18 岁士兵也能理解。

1.3. Security is economics 安全性是经济学

No system is completely, 100% secure against all attacks; rather, systems only need to be protected against a certain level of attacks. Since more security usually costs more money to implement, the expected benefit of your defense should be proportional to the expected cost of the attack. Essentially, there is no point putting a 100 lock on a 1 item. 没有任何系统可以完全、100% 地抵御所有攻击；相反，系统只需要抵御一定程度的攻击。由于更高的安全性通常需要更多的资金来实现，因此防御的预期收益应该与攻击的预期成本成正比。本质上，在价值 1 美元的物品上安装价值 100 美元的锁是没有意义的。

To understand this concept, we can think about physical safes, which come with a rating of their level of security. For instance, a consumer grade safe rated TL-15 is designed to resist attacks for up to 15 minutes by anyone with common tools; it might cost around 3,000. A TL-30, a safe that would resist attacks for up to 30 minutes with common tools, might cost around 5000. Finally, a TXTL-60 (a super high-end safe), which is rated to resist attacks for up to 60 minutes with common tools, a cutting torch, and up to 4 oz of explosives, might cost upwards of

A corollary of this principle is you should focus your energy on securing the weakest links. Security is like a chain: a system is only as secure as the weakest link. Attackers follow the path of least resistance, and they will attack the system at its weakest point. There is no sense putting an expensive high-end deadbolt on a screen door; attackers aren’t going to bother trying to pick the lock when they can just rip out the screen and step through. 这一原则的一个推论是你应该集中精力加固最薄弱的环节。安全就像一条链：系统的安全性取决于最薄弱的环节。攻击者会走阻力最小的路径，他们会攻击系统最薄弱的地方。在纱门上装一个昂贵的高端插销锁是没有意义的；攻击者不会费心去撬锁，他们可以直接撕破纱网走进去。

A closely related principle is conservative design, which states that systems should be evaluated according to the worst security failure that is at all plausible, under assumptions favorable to the attacker. If there is any plausible circumstance under which the system can be rendered insecure, then it is prudent to consider seeking a more secure system. Clearly, however, we must balance this against “security is economics”: that is, we must decide the degree to which our threat model indicates we indeed should spend resources addressing the given scenario. 一个密切相关原则是保守设计，该原则指出系统应根据对攻击者有利的假设下最可能发生的最严重安全故障进行评估。如果系统在任何可能的情况下都可能变得不安全，那么考虑寻找更安全的系统是明智的。然而，显然我们必须权衡这一点与 “安全就是经济” 的观点：也就是说，我们必须根据威胁模型决定我们确实应该投入多大程度的资源来处理给定的场景。

1.4. Detect if you can’t prevent 如果无法预防，就进行检测

Prevention is stopping an attack from taking place, detection is simply learning that the attack has taken place, and response is doing something about the attack. The idea is that if you cannot prevent the attack from happening, you should at least be able to know that the attack has happened. Once you know that the attack has happened, you should find a way to respond, since detection without response is pointless. 预防是阻止攻击发生，检测仅仅是了解攻击已经发生，而响应是采取行动应对攻击。其理念是，如果你无法阻止攻击发生，至少应该能够知道攻击已经发生。一旦你知道攻击已经发生，就应该找到一种方式来响应，因为无响应的检测是徒劳的。

For example, Federal Information Processing Standard (FIPS) 140 provides technical standards for hardware components used by government contractors for encryption. Level III devices—the highest level of security in the standard—are intended to be tamper-resistant. However, Level III devices are very expensive. Level II devices are only required to be tamper-evident, so that if someone tampers with them, this will be visible (e.g., a seal will be visibly broken). This means they can be built more cheaply and used in a broader array of applications. 例如，联邦信息处理标准（FIPS）140 为政府承包商用于加密的硬件组件提供了技术标准。III 级设备——该标准中最高的安全级别——旨在具有防篡改功能。然而，III 级设备非常昂贵。II 级设备只需要具有防篡改证据功能，以便如果有人篡改它们，这种情况会可见（例如，封条会明显破裂）。这意味着它们可以更便宜地制造，并应用于更广泛的应用场景。

When dealing with response, you should always assume that bad things will happen, and therefore prepare your systems for the worst case outcome. You should always plan security in a way that lets you get back to some form of a working state. For example, keeping offsite backups of computer systems is a great idea. Even if your system is completely destroyed, it should be survivable since all your data is backed up in some other location. 在处理响应时，你应该始终假设坏事会发生，因此为最坏的结果做好准备。你应该始终以某种方式规划安全，让你能够恢复到某种工作状态。例如，为计算机系统保留异地备份是个好主意。即使你的系统完全被摧毁，也应该能够幸存下来，因为你的所有数据都备份在某个其他地方。

1.5. Defense in depth 纵深防御

The key idea of defense in depth is that multiple types of defenses should be layered together so an attacker would have to breach all the defenses to successfully attack a system. 纵深防御的关键思想是，应将多种类型的防御层叠在一起，这样攻击者就必须攻破所有防御才能成功攻击系统。

Take, for example, a castle defending its king. The castle has high walls. Behind those walls might be a moat, and then another layer of walls. Layering multiple simple defensive strategies together can make security stronger. However, defense in depth is not foolproof—no amount of walls will stop siege cannons from attacking the castle. Also, beware of diminishing returns—if you’ve already built 100 walls, the 101st wall may not add enough additional protection to justify the cost of building it (security is economics). 以一座保卫国王的城堡为例。城堡有高墙。墙后可能有护城河，然后是另一层墙。将多个简单的防御策略层叠在一起可以使安全性更强。然而，纵深防御并非万无一失——再多的墙也无法阻止攻城炮攻击城堡。此外，要警惕收益递减——如果你已经建了 100 道墙，第 101 道墙可能无法提供足够的额外保护来证明其建造成本是合理的（安全性是经济学）。

Another example of defense in depth is through a composition of detectors. Say you had two detectors, D1 and D2, each of which have some rate of generating false alarms (alerts that are not actually a security compromise) and some rate of missed attacks (security compromises that didn’t trigger any alert). One way to use the two detectors would be to have them in parallel, meaning that either detector going off would trigger a response. This would increase the false alarm rate and decrease the rate of missed attacks. Or, we could also have the detectors in series, meaning that both detectors have to alert in order to trigger a response. In this case, the false alarm rate would decrease while the rate of missed attacks would increase. 纵深防御的另一个例子是通过探测器的组合。假设你有两个探测器 D1 和 D2，每个探测器都有一定的误报率（并非实际安全漏洞的警报）和一定的漏报率（未触发任何警报的安全漏洞）。一种使用这两个探测器的方法是并联，这意味着任何一个探测器触发都会引起响应。这会增加误报率并降低漏报率。或者，我们也可以串联探测器，这意味着两个探测器都必须发出警报才能触发响应。在这种情况下，误报率会降低，而漏报率会增加。

1.6. Least privilege 最小权限原则

Consider a research building that is home to a team of scientists as well as other people hired to maintain the building (janitors, IT staff, kitchen staff, etc.) Some rooms with sensitive research data might be only accessible to trusted scientists. These rooms should not be accessible to the others (e.g., kitchen staff). For best security practices, any one party should only have as much privilege as it needs to play its intended role. 考虑一个研究大楼，里面有一组科学家以及其他受雇维护大楼的人员（清洁工、IT 员工、厨房员工等）。一些存放敏感研究数据的房间可能只对受信任的科学家开放。这些房间不应该对其他人（例如厨房员工）开放。为了达到最佳的安全实践，任何一方只应拥有其扮演预期角色所需的权限。

In technical terms, give a program the set of access privileges that it legitimately needs to do its job—but nothing more. Try to minimize how much privilege you give each program and system component. 用技术术语来说，就是只给一个程序完成其工作所需的合法访问权限——不多也不少。尽量减少你给每个程序和系统组件的权限。

Least privilege is an enormously powerful approach. It doesn’t reduce the probability of failure, but it can reduce the expected cost of failures. The less privilege that a program has, the less harm it can do if it goes awry or becomes subverted. 最小权限原则是一种非常强大的方法。它不能降低失败的概率，但可以降低失败的预期成本。一个程序的权限越少，如果它出错或被颠覆，它能造成的损害就越小。

For instance, the principle of least privilege can help reduce the damage caused by buffer overflow. (We’ll discuss buffer overflows more in the next chapter.) If a program is compromised by a buffer overflow attack, then it will probably be completely taken over by an intruder, and the intruder will gain all the privileges the program had. Thus, the fewer privileges that a program has, the less harm is done if it should someday be penetrated by a buffer overflow attack. 例如，最小权限原则可以帮助减少由缓冲区溢出造成的损害。（我们将在下一章更详细地讨论缓冲区溢出。）如果一个程序被缓冲区溢出攻击所攻破，那么它很可能会被入侵者完全控制，入侵者将获得该程序拥有的所有权限。因此，一个程序的权限越少，如果它某天被缓冲区溢出攻击渗透，造成的损害就越小。

How does Unix do, in terms of least privilege? Answer: Pretty lousy. Every program gets all the privileges of the user that invokes it. For instance, if I run a editor to edit a single file, the editor receives all the privileges of my user account, including the powers to read, modify, or delete all my files. That’s much more than is needed; strictly speaking, the editor probably only needs access to the one file being edited to get the job done. 在最小权限方面，Unix 做得如何？答案是：相当糟糕。每个程序都获得调用它的用户的全部权限。例如，如果我运行一个编辑器来编辑单个文件，该编辑器会获得我用户账户的所有权限，包括读取、修改或删除我所有文件的权力。这远远超出了需要；严格来说，编辑器可能只需要访问正在编辑的那个文件就可以完成工作。

How is Windows, in terms of least privilege? Answer: Just as lousy. 在最小权限方面，Windows 做得如何？答案是：同样糟糕。

Mobile phones do much better. Each app is sandboxed, and typically cannot access other apps’ data. If one app is malicious or compromised, the damage it can do is therefore limited. 移动电话做得好得多。每个应用都被沙箱化，通常无法访问其他应用的数据。因此，如果一个应用是恶意的或被攻破，它能造成的损害是有限的。

1.7. Separation of responsibility 责任分离

Split up privilege, so no one person or program has complete power. Require more than one party to approve before access is granted. 分割权限，使任何个人或程序都没有完全的权力。要求在授予访问权限之前，必须有多方批准。

In a nuclear missile silo, for example, two launch officers must agree before the missile can be launched. 例如，在核导弹发射井中，必须有两名发射官同意才能发射导弹。

Another example of this principle in action is in a movie theater. To watch a movie, you first pay the cashier and get a ticket stub. Then, when you enter the movie theater, a different employee tears your ticket in half and collects one half of it, putting it into a lockbox. Why bother giving you a ticket that 10 feet later is going to be collected from you? One answer is that this helps prevent insider fraud. Employees might be tempted to let their friends watch a movie without paying. The presence of two employees makes an attack harder, since both employees must work together to let someone watch a movie without paying. 这个原则在实践中的另一个例子是在电影院。要看电影，你首先向收银员付款并获得票根。然后，当你进入影院时，另一名员工将你的票撕成两半，收集其中一半并放入一个锁箱中。为什么要给你一张 10 英尺后就会被收走的票呢？一个答案是这有助于防止内部欺诈。员工可能会想让他们的朋友不付钱看电影。两名员工的存在使得攻击更加困难，因为两名员工必须合作才能让某人不付钱看电影。

In summary, if you need to protect a highly sensitive action, require multiple parties to work together to take that action, since it is more likely for a single party to be malicious than for all of the parties to be malicious and collude with one another. 总之，如果你需要保护一个高度敏感的操作，就要求多方合作来执行该操作，因为单个一方是恶意的可能性比所有方都是恶意并相互勾结的可能性要大。

1.8. Ensure complete mediation 确保完全中介

When enforcing access control policies, make sure that you check every access to every object. This kind of thinking is helpful to detect where vulnerabilities could be. As such, you have to ensure that all access is monitored and protected. One way to accomplish this is through a reference monitor, which is a single point through which all access must occur. 在执行访问控制策略时，确保你检查对每个对象的每一次访问。这种思维方式有助于发现漏洞可能存在的地方。因此，你必须确保所有访问都受到监控和保护。实现这一点的一种方法是通过引用监视器，这是一个所有访问都必须通过的单点。

A security checkpoint at an airport is a good example of a reference monitor. All passengers are funneled through one or a small number of checkpoints, where they be scanned. If we make sure that these checkpoints are handled correctly and there is no way to bypass the checkpoint, this will be enough to protect hundreds of gates at the terminals. 机场的安检点是引用监视器的一个很好的例子。所有乘客都被引导通过一个或少数几个检查点，在那里他们会接受扫描。如果我们确保这些检查点处理得当，并且没有办法绕过检查点，这就足以保护航站楼的数百个登机口。

1.9. Shannon’s Maxim 香农箴言

Shannon’s Maxim states that the attacker knows the system that they are attacking. 香农箴言指出，攻击者了解他们正在攻击的系统。

“Security through obscurity” refers to systems that rely on the secrecy of their design, algorithms, or source code to be secure. The issue with this, however, is that it is extremely brittle and it is often difficult to keep the design of a system secret from a sufficiently motivated attacker. Historically, security through obscurity has a lousy track record: many systems that have relied upon the secrecy of their code or design for security have failed miserably. “通过隐匿获得安全”指的是依赖其设计、算法或源代码的保密性来确保安全的系统。然而，这种做法的问题在于它非常脆弱，而且通常很难向一个有足够动机的攻击者保守系统设计的秘密。从历史上看，“通过隐匿获得安全”的记录很差：许多依赖代码或设计保密性来确保安全的系统都惨遭失败。

Someone relying on security through obscurity might reason like this: “this system is so obscure, only 100 people around the world understand anything about it, so what are the odds that an adversary will bother attacking it?” One problem with such reasoning is that such an approach is self-defeating in the long run. If the system becomes more popular, there will be more incentive to attack it, and then we cannot rely on its obscurity to keep attackers away. 依赖“通过隐匿获得安全”的人可能会这样想：“这个系统如此晦涩，全世界只有 100 人了解它，那么对手费心攻击它的几率有多大？”这种推理的一个问题是，从长远来看，这种方法是自欺欺人的。如果系统变得更受欢迎，攻击它的动机就会更大，届时我们就不能依靠它的晦涩来抵御攻击者了。

This doesn’t mean that open-source applications are necessarily more secure than closed-source applications. But it does mean that you shouldn’t trust any system that relies on security through obscurity, and you should probably be skeptical about claims that keeping the source code secret makes the system significantly more secure. 这并不意味着开源应用程序必然比闭源应用程序更安全。但这确实意味着，你不应该信任任何依赖“通过隐匿获得安全”的系统，并且你应该对声称保密源代码能显著提高系统安全性的说法持怀疑态度。

As such, you should never rely on obscurity as part of your security. Always assume that the attacker knows every detail about the system that you are working with (including its algorithms, hardware, defenses, etc.) 因此，你不应该将隐匿作为你安全措施的一部分。始终假设攻击者了解你正在使用的系统的每一个细节（包括其算法、硬件、防御措施等）。

A closely related principle is Kerckhoff’s Principle, which states that cryptographic systems should remain secure even when the attacker knows all internal details of the system. (We’ll discuss cryptographic systems more in the cryptography section.) The secret key should be the only thing that must be kept secret, and the system should be designed to make it easy to change keys that are leaked (or suspected to be leaked). If your secrets are leaked, it is usually a lot easier to change the key than to replace every instance of the running software. 一个密切相关的原则是柯克霍夫原则，该原则指出，即使攻击者知道系统的所有内部细节，密码系统也应保持安全。（我们将在密码学部分更详细地讨论密码系统。）密钥应该是唯一必须保密的东西，并且系统应该设计成可以轻松更换泄露（或怀疑泄露）的密钥。如果你的秘密泄露了，更换密钥通常比更换所有正在运行的软件实例要容易得多。

1.10. Use fail-safe defaults 使用故障安全默认设置

Choose default settings that “fail safe”, balancing security with usability when a system goes down. Ensure that if the security mechanisms fail or crash, they will default to secure behavior, not to insecure behavior. 选择“故障安全”的默认设置，在系统出现故障时平衡安全性与可用性。确保如果安全机制失效或崩溃，它们将默认为安全行为，而不是不安全行为。

For example, when we get to firewalls, you will learn about default-deny policies, which start by denying all access, then allowing only those which have been explicitly permitted. Firewalls must explicitly decide to forward a given packet or else the packet is lost (dropped). If a firewall suffers a failure, no packets will be forwarded. Thus, a firewall fails safe. This is good for security. It would be more dangerous if it had fail-open behavior, since then all an attacker would need to do is wait for the firewall to crash (or induce a crash) and then the fort is wide open. 例如，当我们讲到防火墙时，你将学习到默认拒绝策略，即首先拒绝所有访问，然后只允许那些被明确许可的访问。防火墙必须明确决定转发一个给定的数据包，否则该数据包将被丢失（丢弃）。如果防火墙发生故障，任何数据包都无法转发。因此，防火墙是故障安全的。这对安全是有利的。如果它是故障开放行为，那将更加危险，因为那样攻击者只需要等待防火墙崩溃（或诱导其崩溃），然后整个堡垒就门户大开了。

1.11. Design security in from the start 从一开始就设计安全性

Trying to retrofit security to an existing application after it has already been spec’ed, designed, and implemented is usually difficult. At that point, you’re stuck with whatever architecture has been chosen, and you don’t have the option of decomposing the system in a way that ensures least privilege, separation of privilege, complete mediation, defense in depth, and other good properties. Backwards compatibility is often particularly painful, because you can be stuck with supporting the worst insecurities of all previous versions of the software. 在现有应用程序已经完成规格制定、设计和实现之后，再为其添加安全性通常很困难。到那时，你已经受制于所选择的架构，无法以确保最小权限、权限分离、完全中介、纵深防御和其他良好特性的方式来分解系统。向后兼容性通常尤其痛苦，因为你可能不得不支持软件所有先前版本中最严重的不安全性。

1.12. The Trusted Computing Base (TCB) 可信计算基 (TCB)

Now that you understand some of the important principles for building secure systems, we will try to see what you can do at design time to implement these principles and improve security. The question we want to answer is how can you choose an architecture that will help reduce the likelihood of flaws in your system, or increase the likelihood that you will be able to survive such flaws? We begin with a powerful concept, the notion of a trusted computing base, also known as the TCB. 既然你已经了解了构建安全系统的一些重要原则，我们将尝试看看在设计阶段你可以做些什么来实现这些原则并提高安全性。我们想要回答的问题是，你如何选择一个架构来帮助减少系统中出现缺陷的可能性，或者增加你能够在这种缺陷中幸存的可能性？我们从一个强大的概念开始，即可信计算基，也称为 TCB。

In any system, the trusted computing base (TCB) is that portion of the system that must operate correctly in order for the security goals of the system to be assured. We have to rely on every component in the TCB to work correctly. However, anything that is outside the TCB isn’t relied upon in any way; even if it misbehaves or operates maliciously, it cannot defeat the system’s security goals. Generally, the TCB is made to be as small as possible since a smaller, simpler TCB is easier to write and audit. 在任何系统中，可信计算基 (TCB) 是系统中为保证系统安全目标必须正确运行的那部分。我们必须依赖 TCB 中的每个组件都能正确工作。然而，任何在 TCB 之外的东西都不以任何方式被依赖；即使它行为不当或恶意操作，也无法破坏系统的安全目标。通常，TCB 被设计得尽可能小，因为一个更小、更简单的 TCB 更容易编写和审计。

Suppose the security goal is that only authorized users are allowed to log into my Linux server using SSH. What is the TCB? Well, the TCB includes the SSH daemon, since it is the one that makes the authentication and authorization decisions; if it has a bug, or if it was programmed to behave maliciously, then it will be able to violate my security goal by allowing access to unauthorized users. The TCB also includes the operating system, since the operating system has the power to tamper with the operation of the SSH daemon (e.g., by modifying its address space). Likewise, the CPU is in the TCB, since we are relying upon the CPU to execute the SSH daemon’s machine instructions correctly. Suppose a web browser application is installed on the same machine; is the web browser in the TCB? Hopefully not! If we’ve built the system in a way that is at all reasonable, the SSH daemon is supposed to be protected (by the operating system’s memory protection) from interference by unprivileged applications, like a web browser. 假设安全目标是只允许授权用户使用 SSH 登录我的 Linux 服务器。那么 TCB 是什么？嗯，TCB 包括 SSH 守护进程，因为它是做出认证和授权决定的；如果它有 bug，或者被编程为恶意行为，那么它将能够通过允许未经授权的用户访问来违反我的安全目标。TCB 还包括操作系统，因为操作系统有权篡改 SSH 守护进程的操作（例如，通过修改其地址空间）。同样，CPU 也在 TCB 中，因为我们依赖 CPU 来正确执行 SSH 守护进程的机器指令。假设同一台机器上安装了 Web 浏览器应用程序；Web 浏览器在 TCB 中吗？希望不在！如果我们以一种合理的方式构建系统，SSH 守护进程应该受到（操作系统的内存保护）保护，免受像 Web 浏览器这样的非特权应用程序的干扰。

TCB Design Principles: Several principles guide us when designing a TCB: TCB 设计原则：在设计 TCB 时，有几个原则可以指导我们：

Unbypassable (or completeness): There must be no way to breach system security by bypassing the TCB. 不可绕过（或完整性）：必须没有办法通过绕过 TCB 来破坏系统安全。

Tamper-resistant (or security): The TCB should be protected from tampering by anyone else. For instance, other parts of the system outside the TCB should not be able to modify the TCB’s code or state. The integrity of the TCB must be maintained. 防篡改（或安全性）：TCB 应受到保护，免受任何其他人的篡改。例如，TCB 之外的系统其他部分不应能够修改 TCB 的代码或状态。必须维护 TCB 的完整性。

Verifiable (or correctness): It should be possible to verify the correctness of the TCB. This usually means that the TCB should be as simple as possible, as generally it is beyond the state of the art to verify the correctness of subsystems with any appreciable degree of complexity. 可验证（或正确性）：应该可以验证 TCB 的正确性。这通常意味着 TCB 应该尽可能简单，因为通常验证具有任何可观复杂度的子系统的正确性超出了现有技术水平。

Keeping the TCB simple and small is excellent. The less code you have to write, the fewer chances you have to make a mistake or introduce some kind of implementation flaw. Industry standard error rates are 1–5 defects per thousand lines of code. Thus, a TCB containing 1,000 lines of code might have 1–5 defects, while a TCB containing 100,000 lines of code might have 100–500 defects. If we need to then try to make sure we find and eliminate any defects that an adversary can exploit, it’s pretty clear which one to pick!（For example, Windows XP consisted of about 40 million lines of code—all of which were in the TCB. With that much code, it’s a virtual certainty there will be security vulnerabilities somewhere. ） The lesson is to shed code: design your system so that as much code as possible can be moved outside the TCB. 保持 TCB 简单小巧非常好。你写的代码越少，犯错或引入某种实现缺陷的机会就越少。行业标准错误率是每千行代码 1-5 个缺陷。因此，一个包含 1000 行代码的 TCB 可能有 1-5 个缺陷，而一个包含 100,000 行代码的 TCB 可能有 100-500 个缺陷。如果我们需要确保找到并消除任何对手可以利用的缺陷，那么选择哪个就非常清楚了！（例如，Windows XP 由大约 4000 万行代码组成——所有这些代码都在 TCB 中。代码量如此之大，几乎可以肯定某处会存在安全漏洞。 ） 经验是精简代码：设计你的系统，使尽可能多的代码可以移出 TCB。

Benefits of TCBs: The notion of a TCB is a very powerful and pragmatic one as it allows a primitive yet effective form of modularity. It lets us separate the system into two parts: the part that is security-critical (the TCB), and everything else. TCB 的好处：TCB 的概念非常强大和实用，因为它允许一种原始但有效的模块化形式。它让我们能够将系统分为两部分：安全关键部分 (TCB) 和其他所有部分。

This separation is a big win for security. Security is hard. It is hard to build systems that are secure and correct. The more stuff the system contains, the harder it is to assure its security. If we are able to identify a clear TCB, then we will know that only the parts in the TCB must be correct for the system to be secure. Thus, when thinking about security, we can focus our effort where it really matters. And, if the TCB is only a small fraction of the system, we have much better odds at ending up with a secure system: the less of the system we have to rely upon, the less likely that it will disappoint. 这种分离对安全来说是一大胜利。安全是困难的。构建安全和正确的系统是困难的。系统包含的东西越多，保证其安全性就越难。如果我们能够确定一个清晰的 TCB，那么我们就会知道，只有 TCB 中的部分必须是正确的，系统才能安全。因此，在考虑安全性时，我们可以将精力集中在真正重要的地方。而且，如果 TCB 只是系统的一小部分，我们获得安全系统的几率就会大得多：我们依赖的系统部分越少，它让我们失望的可能性就越小。

In summary, some good principles are: 总之，一些好的原则是：

Know what is in the TCB. Design your system so that the TCB is clearly identifiable. 了解 TCB 中有什么。设计你的系统，使 TCB 清晰可辨。

Try to make the TCB unbypassable, tamper-resistant, and as verifiable as possible. 尽量使 TCB 不可绕过、防篡改且尽可能可验证。

Keep It Simple, Stupid (KISS). The simpler the TCB, the greater the chances you can get it right. 保持简单，傻瓜 (KISS)。TCB 越简单，你做对的机会就越大。

Decompose for security. Choose a system decomposition/modularization based not just on functionality or performance grounds—choose an architecture that makes the TCB as simple and clear as possible. 为安全而分解。选择一个系统分解/模块化方案，不仅仅基于功能或性能的考虑——选择一个能使 TCB 尽可能简单和清晰的架构。

1.13. TOCTTOU Vulnerabilities TOCTTOU 漏洞

A common failure of ensuring complete mediation involves race conditions. The time of check to time of use (TOCTTOU) vulnerability usually arises when enforcing access control policies such as when using a reference monitor. Consider the following code, which might run in a bank ATM: 确保完全中介的一个常见失败涉及竞争条件。检查时间到使用时间 (TOCTTOU) 漏洞通常在执行访问控制策略时出现，例如在使用引用监视器时。考虑以下可能在银行 ATM 机上运行的代码：

procedure withdraw(amount w) {
    // contact central server to get balance
    1. let b := balance
    2. if b < w, abort

    // contact central server to set the balance
    3. set balance := b - w
    4. give w dollars to the user
}

This code takes as input the amount you want to withdraw, w. It then looks up your bank balance in the database. If you do not have enough money in your account to withdraw the specified amount, it aborts the transaction. If you do have enough money, it decrements your balance by the amount that you want to withdraw and then dispenses the cash to you. 这段代码将您想提取的金额 w 作为输入。然后它会在数据库中查找您的银行余额。如果您的账户中没有足够的钱来提取指定的金额，它会中止交易。如果您有足够的钱，它会将您的余额减去您想提取的金额，然后将现金发给您。

Suppose that multiple calls to withdraw can take place concurrently (i.e. two separate ATMs). Also suppose that the attacker can somehow pause the execution of procedure on one ATM. 假设可以同时进行多次取款调用（即两台独立的 ATM 机）。再假设攻击者可以以某种方式在一台 ATM 机上暂停程序的执行。

So suppose that your current account balance is 100 and you want to withdraw 100. At the first ATM, suppose you pause it after step 2. Then, you go over to the second ATM and proceed to withdraw 100 successfully (meaning that your account balance should now be 0). You then go back to the first ATM and unpause the procedure; since the account balance check was completed before you withdrew the money from the second ATM, the first ATM still thinks you have 100 in your account, and it allows you to withdraw another 100! So despite your bank account having only 100 to begin with, you ended up with 200. 因此，假设您当前的账户余额为 100 美元，您想提取 100 美元。在第一台 ATM 机上，假设您在第 2 步后暂停了它。然后，您去到第二台 ATM 机，成功提取了 100 美元（这意味着您的账户余额现在应该是 0 美元）。然后您回到第一台 ATM 机并取消暂停该过程；由于账户余额检查是在您从第二台 ATM 机取钱之前完成的，第一台 ATM 机仍然认为您的账户中有 100 美元，并允许您再提取 100 美元！因此，尽管您的银行账户最初只有 100 美元，您最终却得到了 200 美元。

This is known as a Time-Of-Check To Time-Of-Use (TOCTTOU) vulnerability, because between the check and the use of whatever state was checked, the state somehow changed. In the above example, between the time that the balance was checked and the time that balance was set, the balance was somehow changed. 这被称为“检查时到使用时”（Time-Of-Check To Time-Of-Use，简称 TOCTTOU）漏洞，因为在检查状态和使用该状态之间，状态以某种方式发生了变化。在上面的例子中，在检查余额和设置余额之间，余额以某种方式发生了变化。