大家好！我是大聪明-PLUS！

这是有关嵌入式Linux安全性的文章的第二部分。

在第一部分中，我们讨论了一些安全概念、威胁建模、安全启动、代码和数据加密、加密密钥和密钥存储技术。

在第二部分中，让我们继续讨论提高嵌入式 Linux 设备安全性的技术，包括安全编码、静态分析工具、运行时保护、模糊测试工具、权限、Linux 功能、强制访问控制、沙盒、更新系统和网络安全。

本文的第一部分讨论了代码和数据的加密。但是，如果您运行的应用程序存在可能被利用的漏洞，那么仅通过加密来保护代码和数据是不够的。

这就是为什么我们需要保护应用程序安全。有很多技术可以做到这一点，首先是安全编码。

安全编码

如果应用程序具有攻击媒介（用户输入、配置文件、网络通信等），则可以利用错误来利用系统。

尤其是使用 C/C++ 等内存不安全语言编写的程序，缓冲区溢出等错误可能会被用于堆栈破坏和格式化字符串等攻击。

举个例子，这是一个在 Linux 内核（从 2.6.34 到 5.2.x 版本）中发现的缓冲区溢出漏洞，存在于 vhost 功能将 virtqueue 缓冲区转换为 IOV 的过程中。特权客户机用户能够在迁移过程中向主机传递长度无效的描述符，从而利用此漏洞提升其在主机上的权限。

 123456789
10
11
12
13
14
15
16
17
18
19
20
21
22

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 34ea219936e3f..acabf20b069ef 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -2180,7 +2180,7 @@ static int get_indirect(struct vhost_virtqueue *vq, /* If this is an input descriptor, increment that count. */ if (access == VHOST_ACCESS_WO) { *in_num += ret;
- if (unlikely(log)) {
+ if (unlikely(log && ret)) { log[*log_num].addr = vhost64_to_cpu(vq, desc.addr); log[*log_num].len = vhost32_to_cpu(vq, desc.len); ++*log_num;
@@ -2321,7 +2321,7 @@ int vhost_get_vq_desc(struct vhost_virtqueue *vq, /* If this is an input descriptor,* increment that count. */ *in_num += ret;
- if (unlikely(log)) {
+ if (unlikely(log && ret)) { log[*log_num].addr = vhost64_to_cpu(vq, desc.addr); log[*log_num].len = vhost32_to_cpu(vq, desc.len); ++*log_num;

该漏洞已注册为CVE-2019-14835，并于2019年修复。实际上，虚拟机（客户机）内的用户可以利用此漏洞获取主机的 root 权限。该漏洞（以及许多其他漏洞）在 Linux 内核中已经存在多年！

软件终究会存在 bug，但我们可以尝试减少 bug。为此，我们可以使用静态分析工具。

静态分析工具能够分析源代码（无需运行程序），从而在程序运行时遇到问题之前发现它们。这些工具可以发现诸如空指针引用、内存泄漏、整数溢出、越界访问、初始化前使用等等程序错误！

有很多优秀的开源工具（例如 cppcheck、splint、clang 等）和商业工具（例如 Coverity、PC-Lint 等）可用于静态代码分析，从编译器开始，它们通常内置有静态分析工具，会在编译代码时生成警告或错误。这就是为什么我们永远不应该忽略编译器警告，对吧？

总之，我不会在这里深入探讨静态分析工具。如果你感兴趣，可以看看“使用静态分析工具寻找漏洞”。因此，降低应用程序安全漏洞风险的第一步是切勿忽略编译器警告并使用静态分析工具。但有些漏洞在源代码级别很难识别，有时甚至无法识别。因此，我们可能需要在应用程序中添加运行时保护措施。

运行时保护

运行时保护使得对应用程序进行动态分析成为可能。这意味着您的程序将受到运行时执行的保护和检查。

例如，AddressSanitizer (ASan) 是一款非常有趣的插桩工具，由谷歌安全研究人员创建，用于识别 C 和 C++ 程序中的内存访问问题。在启用 AddressSanitizer 的情况下编译 C/C++ 应用程序的源代码时，该程序将在运行时进行插桩，以识别并报告内存访问错误。

另一个例子是地址空间布局随机化，这是一种计算机安全技术，它随机排列进程关键数据区域（文本、堆栈、堆、库等）的地址空间位置。因此，如果您关心嵌入式 Linux 设备的安全性，则应该启用 ASLR，至少在 Linux 内核中启用。

Valgrind是另一个非常有用的工具，可以帮助检测与内存相关的问题，如泄漏和数据争用。

当然，这其中也存在一些权衡。虽然这些工具可以在运行时识别错误和安全漏洞，但它们可能会影响应用程序性能，并使系统调试变得更加困难。

此外，要使用这些工具查找错误，你必须确保代码中存在错误的部分能够运行。更好的是，应用程序的测试覆盖率应该接近 100%。模糊测试工具或许能帮到你。

模糊测试是一种自动化软件测试技术，涉及向程序提供无效、意外或随机数据作为输入。

然后监视程序是否存在异常，例如崩溃、内置代码断言失败或潜在的内存泄漏。

有很多免费和开源的模糊测试工具可供使用，包括 AFL（美国模糊测试循环）和 syzkaller（Linux 内核模糊测试器）。

这正是安全研究人员和威胁行为者用来查找软件安全漏洞的工具。有时，他们甚至会自己编写模糊测试工具，而不是使用流行的框架。这样做是有代价的，因为一些安全研究人员在BugBounty平台上通过查找软件漏洞赚取了数百万美元。

因此，如果您关心安全性，请尝试使用模糊测试工具测试您的嵌入式 Linux 系统！

最终，模糊测试、静态分析和运行时保护等技术和工具将有助于显著减少软件中的错误数量。但这并不意味着您的软件发布时不会出现任何错误！软件总是会存在错误，因此我们需要另一层保护，以防软件被利用。这就引出了系统权限。

权限

缓解漏洞利用风险的一种方法是不要以 root（超级用户）权限运行程序！您应该利用操作系统的访问控制机制，以非特权用户身份运行进程，并在仅授予运行所需资源访问权限的组中运行进程。

这被称为最小特权原则，是设计安全系统的规则之一。应用程序应该仅以完成其工作所需的权限运行。

但问题是，有时我们需要“root 权限”来执行某些特权操作（例如设置系统时钟、使用 RAW 套接字等）。在这种情况下，我们需要以 root 身份运行程序，对吗？

错了！解决这个问题的一个方法是使用 Linux 的一项名为 capabilities 的功能。

Linux 功能

Linux 功能是针对以 root 权限运行的进程的细粒度访问控制系统。

Linux 内核将超级用户相关的权限划分为不同的单元，称为“能力”，这些能力可以单独启用或禁用。因此，我们的想法是编写一个程序，使其以 root 身份运行，但只启用完成工作所需的能力。

如果您正在运行利用 Linux 功能的 Linux 发行版，则可以使用getcap工具列出特定程序运行所需的功能：

$ getcap /usr/bin/ping
/usr/bin/ping = cap_net_raw+ep

虽然权限控制机制为进程提供了一部分可用的 root 权限，但它不够灵活。如果您需要对权限进行更严格的控制，可以考虑使用一种称为强制访问控制 (MAC) 的访问控制类型。

强制访问控制

Linux 传统上支持自主访问控制 (DAC)。DAC 是一种访问控制类型，它根据主体的身份和/或所属组（实际上就是我们习惯使用的用户和组标志）来限制对对象的访问。

另一种访问控制称为强制访问控制（MAC）。MAC 是指操作系统限制主体访问或对客体执行某种操作的能力的一种访问控制类型。

MAC 通过 Linux 安全模块 (LSM) 在内核中实现，该框架允许 Linux 内核支持多种计算机安全模型。

实现强制访问控制的两个最著名的 Linux 安全模块是 SELinux 和 AppArmor：

• SELinux 是最流行（且最复杂）的 MAC 实现之一，最初由 NSA 开发，如今用于 Android 和 Fedora 等更大的项目。
• AppArmor 也是一种流行且更加用户友好的 MAC 实现，由 Canonical 支持并用于一些 Linux 发行版，如 Ubuntu 和 Debian。

因此，如果您需要对进程权限进行细粒度的控制，您应该考虑使用 MAC 机制。

但有时限制权限不足以保护系统免受易受攻击的应用程序的攻击。沙盒可以用来缓解这种情况。

应用程序沙盒

沙盒可以将应用程序与系统的其余部分隔离。

Linux 内核中最古老的沙盒机制可能是chroot。但它在安全性方面用处不大，因为它只能隔离文件系统。

虚拟化是应用程序沙盒的另一种形式，但成本太高，尤其是在嵌入式系统中。

目前，嵌入式 Linux 中沙盒应用程序的两种可能解决方案是容器和可信执行环境 (TEE)。

容器

Linux 容器是一个极简文件系统，仅包含运行特定应用程序或应用程序组所需的软件组件。容器与系统其他部分完全隔离运行，仅共享内核。

容器运行时实现利用了 Linux 内核提供的一些功能，包括：

• 命名空间：隔离 Linux 上进程的执行（PID、用户、网络连接、挂载点等）。
• cgroups：允许按进程或进程组划分系统资源（CPU、内存、I/O）。
• seccomp：允许限制进程可以执行的系统调用。

有几种工具可用于管理 Linux 中的容器，包括 LXC、Systemd-nspawn、Podman 和 Docker。

容器本身并不安全，但如果配置得当，我们可以限制容器内各个进程的权限，并控制它们之间的通信，从而减少攻击面，提高系统的安全性。

与安全模块（例如 AppArmor 或 SELinux）结合使用，我们可以大大增强系统的安全性。

但在基于容器的系统中，如果内核被攻破，整个操作系统都将面临风险。在这种情况下，可信执行环境（TEX）是另一层安全保障，可以帮助防止这种情况发生。

可信执行环境

可信执行环境 (TEE) 是一种环境，其中执行的代码和访问的数据在机密性（没有人可以访问数据）和完整性（没有人可以更改代码及其行为）方面受到隔离和保护。

在具有 TEE 的系统中，不可信应用程序 (UA) 在富执行环境 (REE) 上运行，可信应用程序 (TA) 在可信执行环境 (TEE) 上运行。只有在 TEE（安全环境）上运行的可信应用程序才能完全访问主处理器、外设和内存。硬件隔离可保护 TA 免受在主操作系统（非安全环境）上运行的不可信应用程序的攻击。

我们需要硬件支持来实现 TEE，这样我们就可以对硬件（总线、外设、内存区域、中断等）进行分区和隔离，以防止不受信任的应用程序访问受保护的资源。大多数现代处理器都内置了此功能（例如 ARM 的 TrustZone、RISC-V 的 MultiZone 和 Intel SGX）。

我们身边的许多设备都使用了可信执行环境 (TEE)，包括智能手机、机顶盒、视频游戏机和智能电视。目前有一些商业化的 TEE 实现，例如 Kinibi、QSEE 和 iTrustee，以及一些开源实现，例如 Trusty 和 OP-TEE。TEE 可以很好地解决沙盒应用、加密密钥的存储和管理、凭证和敏感数据的存储和管理，以及数字版权信息的保护问题。

尽管我们已经看到了各种缓解措施，但一个拥有数百万行代码的操作系统肯定存在错误和漏洞！对于嵌入式系统和连接设备来说，建立更新系统至关重要，因为安全性是产品的关键特性。

更新系统应在产品开发的早期阶段进行设计，如果可能的话，应具有 OTA（无线）功能。

实施良好的更新系统给产品开发带来了一些真正的挑战，包括通信协议的安全性、更新过程的原子性、防电源故障、带宽和存储使用、回滚功能等。

嵌入式 Linux 的更新系统可以采用一些策略，包括：

• 基于应用程序：易于实现，但操作系统的其余部分怎么办？
• 基于包：更新图像很小，但更新是非原子的，并且包依赖性可能是一个问题。
• 基于图像：使用 A/B 机制是一个很好的解决方案，问题可能是带宽和存储使用情况。
• 基于容器：另一个不错的选择，有助于实现原子、电源故障安全、使用更少带宽、速度更快、停机时间最短且具有回滚能力的更新系统。

如果你正在进行 OTA 更新，你的设备需要网络连接（Wi-Fi、以太网等）。这意味着网络接口会增加系统的攻击面，你需要增加更多安全层来防御攻击。

网络安全

这里的规则很简单：尽可能减少攻击面。但这并不意味着实施起来很容易。但我们可以先关注一些容易实现的目标。

例如，关闭所有未使用/不需要的 TCP/UDP 端口（nmap等工具可以提供帮助），禁用所有未使用的协议（例如 IPv6、PPP 等），设置防火墙规则以防止入站/出站连接，防止 DoS 攻击，防止端口扫描等。

如果您需要与外部设备通信，请始终使用安全连接（VPN、反向 SSH、TLS、HTTPS 等），优先使用公钥认证进行远程连接并禁用以 root 身份登录。

最后，有几种技术可以提高网络安全，我可以写一整篇文章来阐述。我的目的只是提高大家对这个话题的认识，确保我们不会忽视它。

结论

这真是一段疯狂的旅程！在本文的第一部分，我们讨论了一些安全概念、威胁建模、安全启动、代码和数据加密、加密密钥以及密钥存储技术。在第二部分，我们讨论了安全编码、静态分析工具、运行时保护、模糊测试工具、权限、Linux 功能、强制访问控制、沙盒、更新系统以及网络安全。

虽然我没有深入研究这些技术的实现，但我想谈谈我们必须降低风险并实现更安全的嵌入式 Linux 设备的概念和资源。

在安全领域，有一个“纵深防御”的概念，这意味着我们需要始终拥有不止一层或多种类型的防御。想象一下，你是一座城堡的国王。你会如何保护你的城堡？你可以把城堡建在山顶上，建造高大的城墙，在城堡周围设置水坝，在城墙上设置弓箭手，在城堡内安排战士等等。这些都是层层防御。如果攻击者突破了一层防御，将不得不面对下一层，以此类推。

在开发嵌入式 Linux 设备时我们可以应用相同的概念！

说到底，100% 安全的系统是不存在的。攻击者只需一个漏洞就能攻陷设备。问题在于我们想让这个过程变得多么艰难。

因此，我们在设计时应该充分考虑安全性，并充分考虑其中的利弊。一个系统应该“足够安全”。我们应该遵循良好的安全实践，了解可用的技术和工具，并在需要时使用它们。

让我们保护我们的嵌入式 Linux 设备！