理解开源安全中的林纳斯定律
林纳斯定律即“只要有足够多的眼睛关注，任何漏洞都无处隐藏”。那么林纳斯定律是如何应用于开源软件安全的呢？
开源 安全 林纳斯定律
39.69.233.250
虽然无足轻重，但是感觉翻译成林纳斯更习惯一点
来自山东的 Chrome 108.0|Windows 10 用户
2022-12-13T12:16:21.000
58.47.147.106
很多人甚至是资深写代码的，压根儿就忽略了信任这一个步骤，他们用拿来主义习惯略过了一切直奔自己的目的，因为他们认为信任所需的代价从来不需要自己来支付。<br />
所以，开源代码安全所涉及的系统性风险，不外乎源头的“闭眼”审查。
来自湖南益阳的 Firefox 102.0|GNU/Linux 用户
2022-12-13T13:41:30.000
153.0.156.93
你说的有道理
linux [Chrome 108.0|Mac 10.15]
2022-12-13T15:27:06.000
114.219.136.129
不是不知道，而是工作任务繁多导致人不得不忽略一些安全性。
来自江苏苏州的 Chrome 108.0|Mac 10.15 用户
2022-12-13T15:27:46.000
林纳斯定律即“只要有足够多的眼睛关注，任何漏洞都无处隐藏”。那么林纳斯定律是如何应用于开源软件安全的呢？
<ruby> 林纳斯定律 <rt>  Linus's Law </rt></ruby>即“<ruby> 只要有足够多的眼睛关注，任何漏洞都无处隐藏 <rt>  given enough eyeballs, all bugs are shallow </rt></ruby>”。那么林纳斯定律是如何应用于开源软件安全的呢？


![](/data/attachment/album/202212/13/114637dg6w34suucuupucv.jpg)


这篇文章讨论 Linux 对开源软件安全的影响。


开源软件的一个常被赞扬的优点是它的代码能够被任何人审查（安全专家通常称之为“代码审计”）。然而，如果你真的去问很多开源软件用户他们上一次检查代码是什么时候。你大概只能收获他们茫然的眼神或者是喃喃的低语。此外，对于一些相当大型的开源应用，有效地审查每一行代码也是困难的。


根据上述这些稍显不安的事实，我们不得不思考：如果没有人察看这些代码，它是开源还是闭源真的有关系吗？


### 你应该相信开源吗？


计算机爱好者倾向于作出认为开源软件比其他软件更加安全的传统假设。我们通常不会讨论这意味者什么：比较的基础是什么（比什么“更”安全？），或者上述结论是如何得到的。这是一个危险的陈述，因为它表明只要你将一些东西称之为“开源”，它就自动如魔法般地继承了更高的安全性。这不是开源，事实上，这正是开源安全非常反对的。


除非你已经亲自审计并理解了软件代码，否则就不应该假定一个应用程序是安全的。一但你做到了这一点，就可以给予它 <ruby> 终极信任 <rt>  ultimate trust </rt></ruby>。*终极信任* 不是对计算机而言的，而是对你本人而言的，至少在这一应用程序被渗透攻击之前，你信任它是因为你选择了相信它是安全的。


使用者本人是唯一可以对软件代码给予终极信任的人，因此任何人想要获得这样的享受都必须亲自审查代码。相信其他人的话是不管用的。


在你已经亲自审计并理解了软件代码之前，你对一个应用程序给予的最大信任度是一个范围，可以是从 *根本不信任* 到 *相当信任* 之间。然而我们并没有一个关于信任程度的标准对照表，这是一个你必须亲自做出的个人选择。如果你已经从非常信任的人那里听说了一款应用程序是安全的，那么你可能会更信任这个软件，而不是信任那些你没有得到信任建议的东西。


然而，因为无法审计专有（闭源）软件代码，你不可能给予它 *终极信任*。


### 林纳斯定律


现实很骨感，并不是每个人都是程序员，同时也不是每个程序员都有时间检查数以万计的代码行。因此如果你没有亲自审查代码，你就只能选择（一定程度上）相信那些 *亲自* 审查了代码的人。


那么，有哪些人会审查代码呢？


林纳斯定律声称 *只要有足够的眼睛关注，任何漏洞都无处隐藏*，然而我们并不知道多少双眼睛是“足够”的。请不要低估这一数量，应用程序往往经过了远超你想象数量的人员审查。原始开发人员以及后续开发人员显然清楚他们自己写下的代码，不过开源软件往往都是团队成果，开源时间越长，阅读了代码的开发人员越多。新加入的开发人员也必须回顾项目代码的核心部分，因为他们必须学习基础代码以加入新的功能。


同时，为了使开源软件能够在 Linux 发行版上可用，负责开源软件打包分发的开发人员会加入多个项目。有时一个应用程序可能会在不熟悉项目代码的情况下打包，但是大多数时候，开源软件打包人员都是熟悉所打包的项目代码的。这不仅仅是因为他们不想在他们不信任的软件上签名，还由于他们可能不得不修改代码来使得程序能够正确编译。漏洞报告人员和漏洞修复人员一般也是熟悉代码库的，因为他们需要尝试解决小到运行异常，大到程序崩溃的问题。当然，一些漏洞报告人员不是通过亲自审查项目代码，而是通过关注明显未按预期工作的现象，无意中揭示了代码漏洞。系统管理员通常都是通晓用户依赖的重要应用软件的代码的。最后，还有一些安全研究人员，他们专门深入代码内部以揭露潜在的漏洞。


### 信任与透明


很多人先入为主的认为大型软件的审计是基本不可能的，因为它由数以万计的代码行组成。不要被软件运行所需的代码量欺骗了。我们不需要真的阅读数以万计的代码行。代码是高度结构化的，可被利用的代码漏洞仅仅只是其中的一行，不过它通常影响软件的全部功能。


当然，也有例外。有时仅仅一个系统调用或者链接一个有缺陷的库文件就可能引入一系列漏洞。幸运的是，多亏安全研究人员以及漏洞数据库所扮演的积极角色，这些错误相对而言是容易发现的。


一些人指着错误追踪系统，比如 <ruby> <a href="https://cve.mitre.org">  通用漏洞披露 </a> <rt>  Common Vulnerabilities and Exposures </rt></ruby>（CVE）网站，并推断开源软件显而易见是不安全的。毕竟已经向公众公开了大量的安全风险，涉及许多开源项目。但是不要被数据欺骗了。只是因为我们看不到现闭源软件的漏洞，并不意味着闭源软件中不存在漏洞。事实上，已经有很多针对闭源软件的漏洞攻击提出了，闭源软件也是存在漏洞的。区别在于开发者（以及用户）可以查看开源软件的 *所有的漏洞* 从而降低漏洞的影响。这是扩大对开源软件信任的系统机制的一部分，却正是闭源软件软件所缺少的。


对于任何代码而言，可能永远没有“足够的眼睛”来发现漏洞，但是开发社区越壮大、越多样化，越有机会发现和修复代码中的缺陷。


### 信任与人


在开源社区中，参与同一项目的众多开发者已经发现“不安全”的漏洞，却保持沉默的的可能性是微乎其微的，因为人们很少同意以这样的方式合谋。我们已经看到了在应对 COVID-19 的过程中，人类的行为是如何不一致了，在这里也一样：


* 我们都发现了漏洞（病毒）。
* 我们知晓如何避免它传播（待在家里）。
* 然而病毒还是在持续传播，因为总是有一个或者多个人偏离了消减疫情的计划。


开源软件中的漏洞也一样，如果有人发现了漏洞总会公之于众（当然，我们说的是“假如”能够发现）。


然而就专有软件而言，有很大可能参与项目的众多开发者即使注意到不安全的漏洞却仍然保持沉默，因为专有模式依赖于薪水。如果一个开发者将漏洞泄漏出来，他可能只是伤害了该专有软件的声誉，进而降低软件的销售额；或者，在更糟糕的情况下，他可能因此而丢了工作。开发人员拿着薪水秘密地研究软件，往往不会谈论其缺陷。如果你曾经是一名开发者，你可能曾经签署过 NDA （LCTT 译注：<ruby> 保密协议 <rt>  Non-Disclosure Agreement </rt></ruby>），也被培训过商业秘密的重要性，等等不一而足。专有软件鼓励在面对严重的秘密缺陷时保持沉默，更多时候甚至是强制要求沉默。


### 信任与软件


不要信任未经你审计的软件。


如果你必须相信未经你审计的软件，那么选择相信已经面向那些更有可能将软件缺陷公之于众的开发者公开代码的软件。


开源软件并没有比专有软件继承更高的安全性，但是修复它的系统得到了更好的规划、实施和人员配置。




---


via: <https://opensource.com/article/21/2/open-source-security>


作者：[Seth Kenlon](https://opensource.com/users/seth) 选题：[lujun9972](https://github.com/lujun9972) 译者：[CanYellow](https://github.com/CanYellow) 校对：[wxy](https://github.com/wxy)


本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出

