tes*_*r12 28 package-management security apt
我不确定 Ubuntu 包安全的当前程序是什么。
当某些东西最终出现在 Ubuntu 包存储库中时，该包是否由一个受信任的中央团队审核，如果是，会进行什么级别的审核？
我对是否检查包裹感兴趣：
sar*_*old 44
Ubuntu 档案中有几个“口袋”代表不同类型的支持：mainCanonicaluniverse支持in 包，而社区支持包 in 。
软件包必须在 main 中才能在 Ubuntu 的默认安装中。
在开发周期中，开发人员可以提出要包含在 main 中的包。此过程的一部分确定包是否可能与安全相关（例如，以特权运行但与不受信任的用户交互、解析复杂格式等），如果是，则要求 Ubuntu 安全团队执行快速安全审查。我做了很多这样的评论。
我无法对每个提议的软件包进行全面深入的审核。我希望快速了解一个包是否是按照现代安全编程标准以专业方式开发的。
我们检查二进制输出以确保编译的程序和库已使用标准安全缓解措施进行编译，例如位置独立执行支持以获得更好的地址空间布局随机化、堆栈金丝雀、强化源（捕获一些常见的 C 问题）和立即绑定和 RELRO（减轻滥用符号链接的漏洞）。（我们开启了 Stack Clash 漏洞的缓解措施，并在一些较新的处理器中支持 Intel 的控制流完整性检查，但hardening-check尚不知道如何检查这些。）我们还验证了所有 sudo 规则、udev 规则、setuid 或 setgid 位、打包脚本、启动脚本等，以确保包没有意外的特权来源。
我们使用自动扫描器（如Coverity、cppcheck和shellcheck）检查源代码。我们编写了简单的工具来帮助我们发现常见的编程缺陷（这些工具不是为了检测缺陷，而是提供了一种非常快速的方法来检查例如所有内存分配例程、所有网络例程、所有特权操作系统功能的使用等）允许我们快速浏览包中可能有缺陷的代码行。
我们可能会发现缺陷，但更重要的是，我们将了解开发人员在编写代码时是否采取了适当的防御措施。我们将了解软件的工作原理、开发方式以及作者考虑的威胁模型。
我们偶尔会进行模糊测试。（运行模糊测试是简单（有趣）的部分——要从中获得任何价值，还需要对崩溃进行足够的调查以修复它们。这是昂贵的部分。我想做更多这样的事情在未来，但更有价值的是人们为可以在 oss-fuzz基础设施中运行的项目贡献模糊测试，并将结果直接提供给作者。Coverity 也是如此——在每次提交时直接运行 Coverity 并获得添加新问题时的电子邮件比单个“这是 Coverity 发现的问题列表”更有价值。）
根据我们在审计中的发现，我们可能会按原样接受包，或者我们可能会要求更改，或者我们可能不会将包接受到 main.js 中。一些项目作者非常乐意与他们合作，并超越了解决反馈的问题。（几乎所有项目作者都很高兴有人阅读他们的代码并提供反馈。）
所有这些步骤都是一次性任务，用于确定哪些包进入主程序。
Ubuntu 安全团队每天执行 CVE 分类任务。我们有一个 CVE 数据库，用于跟踪哪些软件包受到哪些缺陷的影响、哪些 Ubuntu 版本、哪些版本已修复、可以在何处找到修复程序、支持文档、可能有助于降低问题重要性或影响的缓解措施，以及我们在确定接下来要修复哪些软件包时将使用的优先级。我们从 MITRE、NVD、Debian、邮件列表（公共和私人）等收集数据。
安全研究人员和用户向我们报告问题；我们尽可能进行调查，并在适当的时候将问题转发给上游开发人员。
main 中的包获得全面的安全支持：我们向后移植上游作者的补丁，编写补丁并测试包以降低引入回归的风险。我们无法捕捉到所有的回归，但我们更广泛的视角使我们能够捕捉到上游开发人员可能错过的一些回归。当发现限制或回归或不完整的补丁时，我们会根据需要与上游开发人员和更广泛的社区合作以改进修复。
Universe 中的包是社区支持的：社区成员将为问题准备修复程序、构建包、测试包，并为我们提供补丁以进行构建和分发。我们验证更改的真实性，验证包装更改，构建新包并分发它们。不幸的是，这确实让我们更难知道什么得到了很好的支持，什么没有得到很好的支持。（我们正在努力解决这个问题。）我们的一些企业用户将只使用 main 中的包，以确保他们获得对其环境的安全支持。
任何人都可以提交 debdiff 供我们赞助：在 Launchpad 的源包页面上打开一个错误，将其标记为 Public Security，附加 debdiff，描述您的测试，然后订阅ubuntu-security-sponsors。 准备更改一开始可能看起来很困难，但是有一个庞大的社区围绕着使用 Debian 软件包可以提供帮助。
我们没有一个项目来全面重新审核已经在 main.js 中的包。我们阅读了很多补丁并寻找包中的类似缺陷以及查看周围的代码，但不经常从头开始重新审查包。
我们提交FIPS、CC、STIG 和 CIS认证的LTS 版本。这些提供了用于审核具有不同标准的加密和安全敏感包的监管框架。这些认证对于某些行业很重要。这项工作影响并反馈到分配中。审计人员不一定要寻找缺陷，而是要遵守流程、最低安全标准和配置等。然而，对特别重要的包的正确性的双重检查对某些用户来说是至关重要的保证。
在 Ubuntu 安全团队之外，我们还享有两个美妙社区的综合优势：Debian 和 Ubuntu 开发者社区都与上游开发者和下游用户以及 FOSS 生态系统中其他地方的开发者同行建立了关系。每个人都共同努力提供监督、反馈、合作、沟通。没有任何软件是完美的，但我们社区的共同努力产生了巨大的成果。