[转帖]理解开源安全中的林纳斯定律

理解,开源,安全,纳斯,定律 · 浏览次数 : 0

小编点评

林纳斯定律是指只要有足够的眼睛关注,任何漏洞都无处隐藏,然而我们并不知道多少双眼睛是“足够”的。 开源软件的漏洞报告和修复过程通常需要团队协作,包括开发人员、安全研究人员、漏洞报告人员和系统管理员等多个角色。由于开发人员和安全研究人员通常是熟悉代码库的,可以快速发现和修复代码中的漏洞。而系统管理员通常是通晓用户依赖的重要应用软件的代码的。 因此,虽然开源软件的漏洞报告和修复过程需要团队协作,但开发人员和安全研究人员可以降低漏洞的影响。

正文

https://linux.cn/article-15344-1.html

 

林纳斯定律Linus's Law即“只要有足够多的眼睛关注,任何漏洞都无处隐藏given enough eyeballs, all bugs are shallow”。那么林纳斯定律是如何应用于开源软件安全的呢?

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

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

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

你应该相信开源吗?

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

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

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

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

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

林纳斯定律

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

那么,有哪些人会审查代码呢?

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

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

信任与透明

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

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

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

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

信任与人

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

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

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

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

信任与软件

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

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

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

与[转帖]理解开源安全中的林纳斯定律相似的内容:

[转帖]理解开源安全中的林纳斯定律

https://linux.cn/article-15344-1.html 林纳斯定律Linus's Law即“只要有足够多的眼睛关注,任何漏洞都无处隐藏given enough eyeballs, all bugs are shallow”。那么林纳斯定律是如何应用于开源软件安全的呢? 这篇文章讨

[转帖]Access-Control-Allow-Origin跨域解决及详细介绍

重要声明:本文章仅仅代表了作者个人对此观点的理解和表述。读者请查阅时持自己的意见进行讨论。 本文更新不及时,建议到原文地址浏览:跨域解决及详细介绍。 首先,跨域不是问题。是一种安全机制。 这是你在开发时、上线前就必须提前考虑到的安全问题并且采取合适的手段去避免这个问题带来的程序错误。不过通常情况下,

[转帖]Linux遇到一个内存过高的报警——释放buff/cache

前些天一直受到内存报警,过一段时间就会恢复。由于开发工作有些多,就一直没理它,但是最近几天开始有些频繁了。虽然不影响业务,但是天天报警,还是让人提心吊胆的。因此就抽了一个上午的时间去解决一下这个问题。 排查问题 这台机器安装的是mongodb,因为最近业务增加,内容使用增加是正常的,但是实际的占用内

[转帖]深入理解同步机制---内核自旋锁

https://switch-router.gitee.io/blog/spinlock/ 进程(线程)间的同步机制是面试时的常见问题,所以准备用一个系列来好好整理下用户态与内核态的各种同步机制。本文就以内核空间的一种基础同步机制—自旋锁开始好了 自旋锁是什么 自旋锁就是一个二状态的原子(atomi

[转帖]深入理解Redis的scan命令

熟悉Redis的人都知道,它是单线程的。因此在使用一些时间复杂度为O(N)的命令时要非常谨慎。可能一不小心就会阻塞进程,导致Redis出现卡顿。 有时,我们需要针对符合条件的一部分命令进行操作,比如删除以test_开头的key。那么怎么获取到这些key呢?在Redis2.8版本之前,我们可以使用ke

[转帖]openGauss兑现承诺:7家伙伴发布3.0发行版,3.1 社区创新版9月面世

https://www.doit.com.cn/p/482334.html openGauss Developer Day(openGauss开发者大会)2022在北京顺利召开。这是openGauss开源社区发起并主办的面向数据库开发者的年度活动。 在大会上,openGauss开源社区理事长江大勇发

[转帖]夜莺 监控项目

项目介绍 夜莺监控是一款开源云原生观测分析工具,采用 All-in-One 的设计理念,集数据采集、可视化、监控告警、数据分析于一体,与云原生生态紧密集成,提供开箱即用的企业级监控分析和告警能力。夜莺于 2020 年 3 月 20 日,在 github 上发布 v1 版本,已累计迭代 100 多个版

[转帖]Redis 运维实战 第01期:Redis 复制

https://cloud.tencent.com/developer/article/1986816 作者简介 马听,多年 DBA 实战经验,对 MySQL、 Redis、ClickHouse 等数据库有一定了解,专栏《一线数据库工程师带你深入理解 MySQL》作者。 从这篇文章开始,将出几期 R

[转帖]系统明明有很多内存,却无法分配出一片大块内存?(一文搞定!)

https://zhuanlan.zhihu.com/p/614898901 什么是内存碎片? 内存碎片在Linux很早的时候就已经出现了,了解早期内存碎片产生的历史,有利于我们对它的理解。 假设现在有一块32MB大小的内存,一开始操作系统使用了最小的一块——4MB大小,剩余的内存要留给4个进程使用

[转帖]性能优化必备——火焰图

引言 本文主要介绍火焰图及使用技巧,学习如何使用火焰图快速定位软件的性能卡点。结合最佳实践实战案例,帮助读者加深刻的理解火焰图构造及原理,理解 CPU 耗时,定位性能瓶颈。 背景 当前现状 假设没有火焰图,你是怎么调优程序代码的呢?让我们来捋一下。 1. 功能开关法 想当年我刚工作,还是一个技术小白