Ubuntu Core 16 —— 安全白皮书（上）

最新推荐文章于 2024-06-11 19:35:10 发布

Snapcraft

最新推荐文章于 2024-06-11 19:35:10 发布

阅读量665

点赞数

分类专栏： Snap 文章标签： ubuntu 安全

Snap 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

摘要

Ubuntu Core 是 Ubuntu 跨出的具有革命性的一步。它建立在传统 Linux 之上，重点关注可预测性、可靠性和安全性，同时给开发者相应的自由和控制权限。

问题

Linux 发行版模型是一个业已成熟，容易理解的计算系统模型：它以 Linux 内核为基础，加入一些安装、管理和使用应用程序的底层软件，然后再提供一些默认的应用程序使得用户可以通过其它方式来安装应用程序，其中最常用的是通过网络来提供一个发行版软件档案库。每隔一段时间，便更新内核和软件层，待所有东西都稳定后再发布一个该发行版的新版本。经典的 Ubuntu 已经这样做了很多年，它的持续成功为向前迈进提供了重要的试金石。

虽然 Linux 发行版模型经过验证很好用并且十分灵活，但是将其用于通过互联设备和系统构建的以应用为中心的现代世界时还是面临很多挑战：

OS 认为已安装的软件是可信的
OS 和应用程序是紧耦合的，应用程序必须和特定的 OS 版本匹配，这降低了开发速度
应用程序的改变可能对 OS 产生副作用，反之亦然
系统中某部分升级失败可能阻碍系统中其它部分的升级

描述

背景：经典的 Ubuntu

在讨论 Ubuntu Core 的安全特性和设计之前，我们先来探索下传统 Linux 发行版模型的应用和挑战，尤其是经典的 Ubuntu。

信任模型：发行版

检查 OS 安全性设计的时候，我们首先得理解底层的信任模型。在经典的 Ubuntu 和其它主流的 Linux 发行版中，软件通常以下面的某种方式分发：

1. 作为系统 OS 的一部分
2. 通过一个可信的分发软件的档案库
3. 通过可选的或者由特定站点提供的定制化软件

档案库的完整性

Ubuntu 使用一个签名档案库，所有上传到 Ubuntu 档案库的请求都是受限的：

档案库中只允许存在可验证签名的源码包（档案库中所有的二进制包都是使用 Ubuntu 开发者上传的经过签名的源码包构建的）
已签名的源码包计算校验和（MD5、SHA1 和 SHA256 三种）后添加到 Ubuntu 档案库的 Source 文件中
由已签名的源码包构建的二进制文件计算校验和（MD5、SHA1 和 SHA256 三种）后添加到 Ubuntu 档案库的 Package 文件中
Source 和 Package 文件计算校验和（MD5、SHA1 和 SHA256 三种）后添加到 Ubuntu 档案库的 Release 文件中
Release 文件使用 Ubuntu 档案库的 gpg 密钥签名后保存为 Ubuntu 档案库中的 Releases.gpg 文件

升级

Ubuntu 升级可能在修复某个 Ubuntu 稳定发布版本那些和安全相关或者有重大影响的漏洞时发生，或者作为 Ubuntu 下一个发布版本的一部分。Ubuntu 每 6 个月发布一个新版 OS，通常每 2 年发布一个长期支持版（LTS）。官方对 LTS 版本提供长达 5 年的支持，对临时版本提供 9 个月的支持。在升级过程中，OS 的升级、Ubuntu 档案库的升级或者第三方软件的升级之间是没有区别的。

Ubuntu 开发者更新 Ubuntu 档案库中软件的方式为：首先更新 Debian 源码包（针对某个特定的版本），接着使用 Launchpad 中和开发者账号相关联的 GPG 密钥对其签名，然后将其上传至 Launchpad，并在那里进行验证、构建和自动测试后发布到档案库。无论是开发版本还是现有的稳定版本，这个过程本质上是一样的。唯一的区别是谁有权限上传以及通过上传的过程来控制发布目标。例如，只有 Ubuntu 安全团队的成员才有权限上传到安全口袋。

经典 Ubuntu 中的软件：OS 认为其是可信的

上面所有的内容都在讲述经典 Ubuntu 的信任模型，更具体的说，OS 信任那些通过包管理系统安装的软件。像这样，通过 apt（Ubuntu 的包管理器）安装的软件：

准许在系统中安装文件，并执行安装过程的管理任务
通常可以访问用户会话中可用的任何资源或数据
能访问由 OS 定义的系统服务和数据（传统文件系统的权限、PolicyKit 等）
根据软件的支持状态，可以获得安全和有重大影响的漏洞修复
安装后可选择在特定的限制下运行

发行版模型的挑战

经典 Ubuntu 的发行版是一个经过时间考验，易于理解并且非常灵活的模型。它能很好地适用于许多地方，但在现代快节奏，以 app 为中心的世界的中，它也有一些缺点：

系统将 OS 和安装的软件视为一个整体，而不是区别对待。这可能会使测试复杂化，阻碍重现性，并引入软件之间不可预测的相互影响等
为了维护整个系统的稳定和可靠，Ubuntu 档案库稳定发布版本的更新策略规定了某个发行版中软件的基础版本通常不应更改。相反，漏洞和安全修复必须来自于单独的补丁，而不是上游软件发布的新版本
由于 Ubuntu 的更新策略，通常只会在新的 Ubuntu 版本发布时引入新功能，而不是作为稳定版本更新过程的一部分。这大大降低了开发人员的速度，因为开发人员和用户必须等待六个月，软件的新功能才可以添加到下一个版本的 OS 中
不管是不是来自可信的 Ubuntu 档案库，所有的软件都使用包管理系统进行安装。更具体地说，软件的打包者在安装包时拥有访问系统的全部权限

为了应对 Ubuntu 发行版中固有的一些挑战，经典的 Ubuntu 使用了许多操作系统和工具链的强化特性来防止攻击。我们建议用户只安装官方 Ubuntu 档案库或者可信源中的软件包。

保持最新的状态

如前所述，经典的 Ubuntu 通过签名的档案库使用 apt 包管理工具进行单个包的更新。升级过程包括：

当检测到更新，客户端系统将会下载 Release.gpg、Release、Package 和可选的 Source 文件
Release 文件使用 Release.gpg 和本地 Ubuntu 档案库的 gpg 公钥进行验证
如果 Release 文件验证通过，也就意味着 Package 文件的校验和通过了验证（以及 Source，如果有的话）
如果有更新，将下载更新后的二进制文件，并且它们的校验和须通过 Package 文件内容的验证（源码包通过 Source 文件验证）
下载完所有的更新包后，将安装更新

为了维护安全，系统必须始终保持最新的状态。Ubuntu 的更新系统可以通过多种方式进行配置，比如自动更新（例如，通过 unattended-upgrades（16.04 LTS 中默认安装），但这永远不会自动触发重启）或者在新版本的 Ubuntu 发布时进行提示。

虽然 apt 软件包管理系统有许多值得一提的特点，但它还是缺乏如事务更新和回滚这样的重要特性。例如，即使使用 unattended-upgrades，某些包中的漏洞也可能会阻止系统或其它不相干的包进行更新。当这种情况发生时，需要手动去除破损的更新和修复系统。特定站点的更新策略、APT 代理、管理工具（如 Landscape）和配置管理系统等有时也被用来减轻这些缺陷。

启动安全

经典 Ubuntu 采用了一种典型的启动流程：

固件或者 BIOS 上电自检，然后将控制权交给第一阶段的引导加载程序。根据架构和目标系统的不同，这个引导加载程序可能是标准的 Ubuntu 引导加载程序（GRUB）或者是某些会启动第二阶段引导加载程序的东西
引导加载程序（第一阶段的还是第二阶段的取决于目标系统）启动内核
内核加载 initrd（初始 ramdisk）和需要的内核模块
内核启动 init 进程（Ubuntu 15.04 及以上为 systemd）
init 进程加载控制台登录界面、系统服务和应用程序的服务等

为了主机的安全，这个传统方案要求以上的步骤都不能出问题。

经典 Ubuntu 也支持强制 UEFI 安全启动：

固件或者 BIOS 上电自检，验证固件模块后再验证引导加载程序。如果引导加载程序验证通过，再将控制权交给它
引导加载程序对内核进行验证。如果验证通过，则内核可以通过 UEFI 的方式启动，否则启动失败
然后内核验证启动所需的模块。如果某个模块无法通过验证，那么在加载的时候内核会将其阻塞，并且纪录验证失败。无论哪种情况，initrd 都会被加载
内核开启 init 进程（systemd）
init 进程启动控制台登录、系统服务和应用程序服务等

通过这种方式，根植于设备固件中的可靠性可以用来验证系统运行的内核，以此来防止早期启动受到攻击。这对系统中内核安全策略的执行非常有用。为了增加灵活性和开发人员的需要，系统将支持通过修改固件设置的方式来使用回退模式。

系统、应用程序和网络安全

传统 Ubuntu 系统的安全性是一个复杂的话题，有很多需要关注的因素：

确保系统的安全修复保持最新的状态（Canonical 会为官方支持的软件提供及时的更新）
Ubuntu 使用了许多 OS 和工具链的强化特性。其中包括：
内核强化特性有诸如：零地址保护、禁用 /dev/kmem、只读数据段、编译器堆栈保护、模块 RO/NX、内核地址显示限制和稀有协议黑名单。可选的特性包括阻塞模块加载、过滤系统调用和阻塞 kexec用户空间强化特性有诸如：符号链接和硬链接限制、进程跟踪限制、/proc//maps 限制以及 NX/XD 支持工具链除默认的（栈保护、堆保护、指针困惑、ASLR（栈、libs/mmap、brk 和 VDSO）和增强源）外还增加了一些可选的强化特性（PIE4/exec ASLR、RELRO 和 BIND_NOW）AppArmor 强制访问控制（MAC）约束。AppArmor 可以调解：系统文件和用户数据、网络、库加载、应用程序的执行、Linux 内核的性能、mount、DBus、IPC（信号量、进程追踪和 unix 套接字等）以及在容器层级限制容器和容器内的应用程序
默认为官方支持软件的 Ubuntu 实现。它们包括：
安全够用的文件权限（包括文件系统的能力和受限的 SUID 二进制文件）禁止使用众所周知的系统账号登录（如 root 和 www-data 等）在默认安装时开放网络端口的能力限制在如 dhcp 客户端和 avahi 等网络基础设施服务之内使用强密码散列法（SHA512crypt）安全够用的默认配置限制 DBus 系统服务的 DBus 总线策略和限制 PolicyKit 与特权进程交互的策略无论何时，都以非 root 或特权分隔的方式运行服务为较敏感的软件打开编译器可选的强化特性选项（比如，为 openssh 和 apache2 打开 PIE 等）或者配置强化特性（比如，在 openssh 中打开 seccomp sandbox，在 vfstpd 中打开网络命名空间等）默认安装防火墙软件（ufw 和 iptables）在 AppArmor 配置文件中使能选择的应用程序（比如，虚拟机、LXC 容器和有漏洞历史或者面向网络的软件）
确保基于 deb 包的软件只从可信源进行安装
从 Ubuntu 16.04 开始，所有的风味版都能从 Ubuntu 商店安装 snap 包。在传统的系统中，签名验证是在从 Ubuntu 商店安装 snap 包的时候执行的，这些 snap 包运行在一个严格的沙箱环境中。
重要：经典的 Ubuntu 桌面系统使用 X 视窗系统和 Unity 7 shell 环境，它不会为运行在一个特定用户的图形会话中的图形化应用程序提供隔离（比如，不支持键盘调解、鼠标、截屏、剪切板和 Xsettings 等）。使用 X 和 Unity 7 的图形化应用程序 snap 包应该只从可信的开发者那里进行安装。未来的 Ubuntu 桌面版本将使用 Wayland 显示服务器来解决 X 的安全缺陷。
正确的用户和密码管理。系统安装过程中会设置用户帐户并将其自动添加到 sudo 组，因此这个账号可以通过提示密码的方式以 root 运行命令。
某些懂行的人提供的适当的非缺省配置
确保第三方软件无缺陷

因为经典的 Ubuntu 系统极其灵活并且拥有巨大的实用价值（使用它几乎可以构建任何东西)，所以保障一个已部署系统的整体安全面临许多挑战。Ubuntu 档案库是一个拥有成千上万个包和安全配置的丰富生态系统，它会和不同的软件组件进行交互，这主要由上游的开发人员的意图、Ubuntu 的打包作业和用户以及管理员的使用所够成。例如，当想要设置一个用来服务各种 web 页面的 webserver 系统，管理员可以使用 apt-get 来安装 Apache。由于 Ubuntu 中的 Apache 编译时使用了 PIE 并且提供了合理的默认配置，管理员可能会意外的配置 Apache web 服务器以 root 运行，这样就可以服务于所有的系统文件并暴露敏感的信息。当配置问题修复后，管理员可能会安装一个蹩脚的第三方 PHP 脚本，这使得系统可以以 www-data 用户执行任何程序。在此漏洞被处理后，安装内容管理系统（CMS）中的一个单独漏洞又可能引发类似的攻击。为了防范攻击和暴露敏感信息，管理员可能需要规范配置管理流程或者为 Apache 写一个特定站点的 AppArmor 配置文件来帮助减轻系统的缺陷或错误配置。

复杂的交互同样会影响安全，比如 NetworkManager 预期的 PolicyKit 权限被一个单独安装且没有正确实现其 API 的 DBus 系统服务移除，这可以使其形成针对 NetworkManager 无需身份验证的代理请求。为了杜绝这种情况，站点策略可以规定对已安装的软件进行限制，或者管理员可以编写一个特定站点的 AppArmor 配置文件，以调整 DBus 总线的策略和针对各种服务的 PolicyKit 配置。

更新系统的某部分也可能对另一部分产生副作用，导致组件崩溃或者打开失败。例如，某个 API 调用改变了它的内部默认值或者实现安全检查所需的插件在执行 OS 升级后不再默认安装。

尽管经典 Ubuntu 实现了默认情况下的安全性、可无限扩展和可配置的特性，但这些例子又说明了在像 Ubuntu 这样的传统 Linux 发行版上保持强大的安全状态需要注意的一些事项。

日志

经典 Ubuntu 系统默认使用 systemd 作为 init 进程，因此系统所有的日志信息可以通过 journalctl 命令进行存取。另外，systemd 被配置为将所有日志信息转发到 rsyslog 日志记录服务。这个系统使用一个简化的日志记录方案（可以修改站点需求），包括：

/var/log/auth.log：所有的验证日志（auth.* 和 authpriv.*）
/var/log/syslog：除了验证日志（auth.* 和 authpriv.*）外的所有东西。AppArmor 和 seccomp 的拒绝日志也在这里
/var/log/kern.log：所有的内核日志（kern.*）
/var/log/mail.log：所有的邮件日志（mail.*）
/var/log/audit/audit.log：所有的内核审计子系统日志（包括内核 LSM 拒绝），当然前提是安装了 auditd

rsyslog 默认配置为禁止远程发送和接收日志，并且配置了将上面的一些日志纪录到 /var/log 中的其它日志文件。应用程序可以记录到它们自己的日志文件，并且支持 dmesg 命令。Ubuntu 16.04 桌面版使用 upstart 作为会话总线，它将把会话服务记录到 $HOME/.cache/upstart 文件中。

时钟同步

Ubuntu 16.04 使用 systemd-timesyncd 与远程 NTP 服务器进行时间同步，它默认是启用的。ntp 和 ntpdate 也可用，并且由 Canonical 官方的支持。

数据加密

经典 Ubuntu 提供全磁盘加密（dm-crypt 加密除 /boot 分区外的所有东西）和加密的 HOME（eCryptfs；使用封装有用户密码的不同加密密钥加密每个用户的数据）作为安装过程的一部分。

可信平台模块

TPM 是一个基于标准嵌入式的安全子系统，通常实现为主板上的硬件芯片。经典 Ubuntu 在内核中启用了 TPM 1.2 和 2.0 支持（CONFIG_TCG_TPM 和 CONFIG_HW_RANDOM_TPM）。TPM 1.2 用户空间由 tpm-tools 和 TrouSerS 提供，TPM 2.0 用户空间组件包括 tpm2-tools 和 libtss2-0。TMP 目前还只集成了这些工具到 Ubuntu 中。