基于只读机制的文件系统安全加固方法

摘要

基于只读机制的文件系统安全加固方法，包括如下步骤：准备需要对其安全进行加固的文件系统；构建基于只读机制的对象仓库，对象仓库用于存储和管理文件系统的元数据和文件对象，并通过分支功能跟踪相应的文件系统，并执行切换分支操作以切换到所管理的文件系统；将准备的文件系统导入到对象仓库中，并针对该文件系统创建一个新的分支；将导入的文件系统打包，并将其写入对象仓库中，指定文件系统所属的分支和版本号。本发明在文件系统层面通过不可变基础设施来为容器使用提供安全防护，通过文件系统只读、系统原子化升级和升级安全预警实现了加固容器的使用安全。

权利要求

1.基于只读机制的文件系统安全加固方法，其特征在于，包括如下步骤：步骤S1：准备需要对其安全进行加固的文件系统；

步骤S2：构建基于只读机制的对象仓库；

步骤S3：将步骤S1准备的文件系统导入到步骤S2构建的对象仓库中，并针对该文件系统创建一个新的分支；

步骤S4：将导入的文件系统打包，并将其写入对象仓库中，指定文件系统所属的分支和版本号；

其中，步骤S3所构建的对象仓库，用于存储和管理文件系统的元数据和文件对象，并通过分支功能跟踪相应的文件系统，并执行切换分支操作以切换到所管理的文件系统；

步骤S1中，所准备的文件系统包括只读部分和可写部分，可写部分存储在/etc与/var目录下，只读部分被记载至内存中，可写部分被挂载到只读部分上，只读机制使用dracut工具在/usr目录创建一个只读绑定挂载，确保/usr目录永久为只读状态；

所述步骤S1中，通过如下步骤准备文件系统：

步骤S11：在文件系统中创建一个空的/sysroot目录，确保只读机制将chroot绑定挂载到物理根目录上；

步骤S12：在操作系统启动时，针对文件系统动态创建如下目标：/home → /var/home

/opt → /var/opt

/srv → /var/srv

/root → /var/roothome

/usr/local → /var/usr/local

/mnt → /var/mnt

/tmp → /sysroot/tmp。

2.如权利要求1所述的基于只读机制的文件系统安全加固方法，其特征在于，在针对文件系统进行系统更新时，通过如下步骤进行：对象仓库中存储所有文件系统版本的commit信息，当通过包管理器安装或更新软件包时，对象仓库生成一个新的系统版本以及与该新的系统版本对应的commit提交信息，触发系统的一次原子化升级，采用增量更新的方式，对比新的系统版本所对应的commit与更新前的系统版本所对应的commit的差异，获取增量差异并生成一个包含该差异的压缩补丁，根据增量差异完成更新，同时以新的系统版本的commit信息更新当前系统版本的commit信息。

3.如权利要求2所述的基于只读机制的文件系统安全加固方法，其特征在于，在针对文件系统进行系统更新时，根据增量差异完成更新的方法涉及：对比新的系统版本以及更新前的系统版本的差异，得到所有已被修改的文件，针对每一个已被修改的文件，生成一个包含该文件副本的新目录，应用此前生成的压缩补丁将修改前的文件版本更新到修改后的文件版本。

说明书

基于只读机制的文件系统安全加固方法

技术领域

[0001] 本发明涉及操作系统安全加固技术领域，具体涉及基于只读机制的文件系统安全加固方法。

背景技术

[0002] 容器化、微服务化、云原生是当前计算机行业发展演进的趋势，目前大多数的企业不是正在使用容器，就是考虑使用容器。

[0003] 目前，市面上最常见的容器方案为Docker，尽管容器技术炙手可热、发展迅速，已经能够解决目前的诸多需求，但依然面临着众多挑战。在容器的环境中，由于容器只封装应用和依赖，这使得其必须使用宿主机的内核在进行运作，这种与主机共享内核的模式，在容器能够实现轻量化的同时，也让其受到攻击的范围变得更大。只要获取到容器的权限，即可实现对内核的访问，并且，只要容器中的应用导致内核崩溃，那么整个宿主机系统也会一样崩溃。除此之外，容器还面临着以下安全威胁：

[0004] （1）网络攻击：容器默认使用bridge网络，该网络会创建一个虚拟网桥，连接在同一个网桥之间的容器可以互相访问。当某个容器被入侵时，攻击者可访问到宿主机中的其他容器。同时，攻击者也可通过DDos等方式，攻击容器的服务来耗尽宿主机的资源，从而引起整个宿主机的崩溃。

[0005] （2）特权容器：在启用容器时若使用特权模式(‑‑privileged)，容器将被允许可以访问宿主机上的所有设备，并可以获取大量设备文件的访问权限。

[0006] （3）文件挂载：用户在配置容器时，若将主机的根目录映射到容器中，那么理论上该容器就可对宿主机的文件系统进行任意修改，造成极大的安全风险。

[0007] 因此，阻止攻击者通过容器访问到宿主机的内核和文件系统是降低容器安全风险的重要方式。已有方案主要是采用“安全容器”，例如Kata与gVisor，Kata本质上是一个轻量级虚拟机，gVisor则在宿主机内核之外实现了一个“内核进程”Sentry，两者均采用了阻止容器与宿主机共享内核的方式，目前还没有一种实际的办法从文件系统层面来保证容器使用安全。

发明内容

[0008] 为解决已有技术存在的不足，本发明提供了一种基于只读机制的文件系统安全加固方法，包括如下步骤：

[0009] 步骤S1：准备需要对其安全进行加固的文件系统；

[0010] 步骤S2：构建基于只读机制的对象仓库；

[0011] 步骤S3：将步骤S1准备的文件系统导入到步骤S2构建的对象仓库中，并针对该文件系统创建一个新的分支；

[0012] 步骤S4：将导入的文件系统打包，并将其写入对象仓库中，指定文件系统所属的分支和版本号；

[0013] 其中，步骤S3所构建的对象仓库，用于存储和管理文件系统的元数据和文件对象，并通过分支功能跟踪相应的文件系统，并执行切换分支操作以切换到所管理的文件系统。

[0014] 其中，步骤S1中，所准备的文件系统包括只读部分和可写部分，可写部分存储在/etc与/var目录下，只读部分被记载至内存中，可写部分被挂载到只读部分上，只读机制使用dracut工具在/usr目录创建一个只读绑定挂载，确保/usr目录永久为只读状态。

[0015] 其中，所述步骤S1中，通过如下步骤准备文件系统：

[0016] 步骤S11：在文件系统中创建一个空的/sysroot目录，确保只读机制将chroot绑定挂载到物理根目录上；

[0017] 步骤S12：在操作系统启动时，针对文件系统动态创建如下目标：

[0018] /home → /var/home

[0019] /opt → /var/opt

[0020] /srv → /var/srv

[0021] /root → /var/roothome

[0022] /usr/local → /var/usr/local

[0023] /mnt → /var/mnt

[0024] /tmp → /sysroot/tmp。

[0025] 其中，在针对文件系统进行系统更新时，通过如下步骤进行：对象仓库中存储所有文件系统版本的commit信息，当通过包管理器安装或更新软件包时，对象仓库生成一个新的系统版本以及与该新的系统版本对应的commit提交信息，触发系统的一次原子化升级，采用增量更新的方式，对比新的系统版本所对应的commit与更新前的系统版本所对应的commit的差异，获取增量差异并生成一个包含该差异的压缩补丁，根据增量差异完成更新，同时以新的系统版本的commit信息更新当前系统版本的commit信息。

[0026] 其中，在针对文件系统进行系统更新时，根据增量差异完成更新的方法涉及：对比新的系统版本以及更新前的系统版本的差异，得到所有已被修改的文件，针对每一个已被修改的文件，生成一个包含该文件副本的新目录，应用此前生成的压缩补丁将修改前的文件版本更新到修改后的文件版本。

[0027] 本发明提供的基于只读机制的文件系统安全加固方法，在文件系统层面通过不可变基础设施来为容器使用提供安全防护，通过文件系统只读、系统原子化升级和升级安全预警实现了加固容器的使用安全。

附图说明

[0028] 图1为本发明只读机制所涉及对象仓库的机制逻辑图。

[0029] 图2为基于本发明提供的只读机制对手动修改系统关键文件时的安全预警流程图。

[0030] 图3为基于本发明提供的只读机制根据增量更新机制实现的原子化升级的原理图。

[0031] 图4为本发明的某一实施例的原子化升级中所涉及的文件版本更新示意图。

[0032] 图5为基于本发明提供的只读机制的操作系统原子化升级流程图。

[0033] 图6为基于本发明提供的只读机制的以软件包方式非法更新系统关键文件的安全预警流程图。

具体实施方式

[0034] 为了对本发明的技术方案及有益效果有更进一步的了解，下面结合附图详细说明本发明的技术方案及其产生的有益效果。

[0035] 本发明的基于只读机制的文件系统安全加固方法，通过设计使用了一种只读机制，在文件系统层面通过不可变基础设施来为容器使用提供安全防护，同时，在内核的安全特性模块和Selinux安全访问控制系统的基础上，在文件系统层面通过文件系统只读、系统原子化升级和升级安全预警来加固容器使用安全。

[0036] 其中，不可变基础设施是一种基于只读机制的基础设施管理模式，其中操作系统是不可变的，只能通过替换整个操作系统来进行更新。这种模式可以提高系统的安全性和可靠性，因为这种不可变性可以避免在系统中引入意外的变化和漏洞。只读机制的工作方式就是将整个系统作为单个不可变对象来管理，而不是像传统系统一样管理文件和目录。这种方法使得系统更新变得更加安全和可靠，并且允许管理员轻松回滚更新，以避免不可预知的问题。因此，不可变基础设施和只读机制是相互关联的，只读机制可以帮助实现不可变基础设施的目标，提高系统的可靠性和安全性。

[0037] 借助于只读机制，本发明构建了新的文件系统，该文件系统将基础文件系统分为两部分：只读部分和可写部分。

[0038] 只读部分包含操作系统的基础组件，包含许多必要的系统资源和文件，例如内核、文件系统、共享库等，保证了文件系统的一致性和不可变性，同时也提高了系统的安全性和可靠性。

[0039] 可写部分则可以根据需要进行修改和更新，例如添加、删除或修改文件等操作，主要包含用户的数据和配置文件，存储在/etc与/var目录下。（/etc是配置文件目录，主要存放系统管理所需要的配置文件和子目录，例如系统版本信息、本地时间配置等；/var是变量文件目录，主要存放系统正常运行过程中内容不断变化的文件，例如日志、脱机文件和临时电子邮件文件等。）

[0040] 当系统启动时，只读部分被加载到内存中，作为只读文件系统进行使用。可写部分则被挂载到只读部分之上，作为可写文件系统进行使用。为了避免需要更多的绑定挂载，只读机制采用了一种UsrMove机制，即默认情况下，只读机制会使用dracut工具在/usr目录（此目录为操作系统二进制文件和库文件的主要存储位置）创建一个只读绑定挂载，该目录中包含了用于创建系统只读绑定挂载的代码，因此，通过此过程确保/usr目录永久为只读状态，以防止该目录中系统关键文件的意外损坏。对于使用只读机制的操作系统来说，每个版本之间将共享一个/var可写目录，并且只读机制的核心代码不会涉及该目录中的内容；同时，任何基础设施的实例，包括服务器、容器等各种软硬件，一旦创建部署完成之后便成为只读状态，不可对其进行任何更改，可以保证系统的稳定性和安全性。

[0041] 换而言之，只读机制借助只读绑定挂载将一个只读的文件系统挂载到另一个文件系统上，并且限制了其中挂载点的读写权限。只读绑定挂载的优点是可以将一些重要的系统目录（如/usr、/bin等）和可执行程序限制为只读访问，这样可以更好地保护系统的安全和稳定。当只读绑定挂载完成后，挂载点内的文件和目录都变成只读文件，因此任何对其的修改操作都会被拒绝。这种只读状态可以确保系统的安全性和稳定性，并且能够避免意外的数据损坏或丢失。由于只读绑定挂载是在文件系统层面进行的，因此它的只读状态是永久的，即使系统重新启动也不会改变其状态。

[0042] 其中，Dracut工具是用于自动化Linux引导过程的一组工具，主要用于创建Linux引导镜像，即initramfs。它会从安装的系统中复制工具和文件，并结合通常位于/usr/lib/dracut/modules.d中的Dracut框架来生成引导镜像。

[0043] 只读机制作为一种用于管理操作系统文件的工具和框架，在实际使用过程中，它被用作管理操作系统的升级和版本控制，本发明的基于只读机制的文件系统安全加固方法，基于上文所介绍的只读机制，结合对象仓库实现对各操作系统的管理，具体实现步骤如下：

[0044] 一、准备文件系统

[0045] 首先需要准备一个文件系统，该文件系统包含所有系统的基本元数据和文件内容。该文件系统可以从现有的操作系统镜像中提取，也可以手动创建。不仅如此，为了确保文件系统的完整性、稳定性和可用性，需要对文件目录做以下改变：

[0046] 1、应该包含一个空的/sysroot目录。当启动时，只读机制会将chroot绑定挂载到物理根目录上，以便只读机制在运行时可以始终如一地找到系统数据，无论它是在物理根目录上运行还是在部署内部运行。

[0047] 2、由于只读机制会将/usr目录变成只读的，并将其作为系统版本的一部分进行管理，并且，只读机制所涉及的操作系统的每个版本之间共享一个/var可写目录，操作系统仅在升级过程中保留/var，而每个操作系统部署的chroot目录最终将被垃圾回收，因此需要将一些目录更改到/var目录下，这样才会在系统更新后保留下来，因此需要对其他顶级可写目录进行修改，并且由于默认情况下/var为空，因此需要操作系统在启动时动态创建这些目标:

[0048] /home → /var/home

[0049] /opt → /var/opt

[0050] /srv → /var/srv

[0051] /root → /var/roothome

[0052] /usr/local → /var/usr/local

[0053] /mnt → /var/mnt

[0054] /tmp → /sysroot/tmp

[0055] 二、创建对象仓库

[0056] 在准备好文件系统之后，需要创建一个带有内容寻址的对象仓库，该仓库用于存储文件系统中的元数据和文件内容。

[0057] 图1为对象仓库的机制逻辑图：对象仓库为只读机制的核心，通过分支功能可以跟踪对象仓库中有意义的文件系统树，并执行切换分支操作，有一点需要额外说明，该只读机制仅支持记录和部署完整的、可引导的文件系统树。对象仓库是一个本地或远程存储库，其中包含多个系统版本，并通过特定的仓库格式进行组织和管理。

[0058] 图1中，“提交”表示将当前工作目录下针对相关操作系统的修改保存为一个新版本的操作，“分支”则表示相关操作系统版本的分支，“拉取&部署”表示拉取及部署相关操作系统版本的分支，硬链接（Hard link）是一种在文件系统中创建指向同一个 inode 节点的多个文件名的方式。硬链接创建时不会分配新的磁盘空间，而是在文件系统中创建一个新的文件名，并将其与已有的文件关联起来。因为多个文件名指向同一 inode 节点，所以这些文件名代表的文件实际上是同一个文件。

[0059] 对象仓库中所存储的只读文件系统的数据类型包括：

[0060] 1、元数据

[0061] 对象仓库中存储了每个系统版本的元数据，包括版本号、构建日期、构建主机、父版本等信息。元数据以特定格式进行组织，通常为JSON或Cbor格式。元数据还包括了与该版本相关的分支信息、签名信息以及其他与版本控制相关的信息。

[0062] 2、文件对象

[0063] 对象仓库还存储了每个系统版本的文件对象。文件对象是一个文件或目录，每个对象都有一个唯一的ID，可以用来检查对象是否存在于特定版本中。文件对象以特定的格式进行组织，通常为tar格式或类似tar格式的二进制格式。

[0064] 只读机制实现对象仓库的方式比较灵活，可以选择本地存储或者远程存储，可以使用文件系统或者HTTP服务器进行存储和传输。

[0065] 1、本地文件系统存储

[0066] 对象仓库可以存储在本地文件系统中，通常存储在特定的目录中，例如/repo。对象仓库使用Git风格的版本控制机制，每个版本都以特定的目录结构进行组织，包括版本元数据、文件对象和其他相关文件。

[0067] 2、远程HTTP服务器存储

[0068] 对象仓库也可以存储在远程HTTP服务器上，通常使用HTTP协议进行传输。这种方式可以使得多个客户端共享同一个对象仓库，方便团队协作和分布式部署。对象仓库使用特定的格式进行组织，例如基于HTTP的静态文件服务器或者基于S3的云存储服务等。

[0069] 三、导入文件系统

[0070] 将步骤一文件系统中的元数据和文件内容导入到步骤二的对象仓库中，并创建一个新的分支。

[0071] 四、构建文件系统

[0072] 将导入的文件系统打包，并将其写入对象仓库中，并指定文件系统所属的分支和版本号。

[0073] 如此，每个文件系统对应一个分支和版本号，故采用基于对象仓库的只读机制可并行部署安装多个独立操作系统的多个版本，各操作系统依赖于一个新的顶级目录。

[0074] 只读机制还可对系统的包管理器进行补充，当安装或更新软件包时，并不会对当前正在运行的操作系统进行更改，而是组装一个新的文件系统树，该树对应一个新的系统版本，将新的软件包（软件包为操作系统的重要组成）放在顶部，并将其记录在本地的对象仓库中，为下一次部署引导新的系统版本进行配置。

[0075] 当通过包管理器安装或更新软件包时，该操作会生成一个新的系统版本，并触发系统的一次原子化升级，每一次升级都对应着系统版本的更新，并且由于只读机制的作用，将采用增量更新的方式（后文详述）。若某一文件在系统新版本中进行了修改，在进行更新时，会收到一个包含该文件差异的压缩补丁，且该补丁包含新文件的签名，用于验证系统更新是否成功。

[0076] 对象仓库使用一种特殊的树状结构来组织系统版本，每个版本都有一个唯一的版本号，并且每个版本都有一个或多个父版本。这种版本管理方式使得版本之间形成了一条有向无环图（DAG），可以轻松实现版本回滚和版本切换等操作。

[0077] 图2为基于本发明提供的只读机制对手动修改系统关键文件时的安全预警流程图：如图2所示，当容器中挂载根目录时，不可变基础设施监控会将其判定为危险操作，并对根目录中的内容进行实时监控，若攻击者尝试手动修改系统关键文件，会发现文件为只读权限，无法修改，只读机制此时会发出预警信息，提醒开发人员有非法操作。由此说明，在只读机制的作用下，即使是在容器中挂载了宿主机目录，恶意代码也无法轻易对宿主机的重要文件或目录进行更改，降低了容器逃逸的风险。

[0078] 本发明中，根目录是Linux系统中的重要目录，它是整个文件系统的起点和根节点，所有其他目录和文件都是相对于根目录而言的

[0079] 最后，由于对象仓库通过分支及版本号对文件系统进行管理，故可支持多种压缩算法和增量更新机制，有效地减少存储和网络传输的数据量，降低操作系统更新的成本，并提高操作系统的安全性和稳定性。

[0080] 具体的，请参见图3所示，（图3中，“远端仓库”即对应存储在远端的对象仓库）为基于本发明提供的只读机制根据增量更新机制实现的原子化升级的原理图：当通过包管理器安装或更新软件包时，该操作会生成一个新的系统版本，并触发系统的一次原子化升级，每一次升级都对应着系统版本的更新，并且由于只读机制的作用，将采用增量更新的方式。若某一文件在系统新版本中进行了修改，在进行更新时，会收到一个包含该文件差异的压缩补丁，且该补丁包含新文件的签名，用于验证系统更新是否成功。

[0081] 在制作系统版本时，每一次版本都会构成一次commit提交信息，并保存至对象仓库，且系统会保存本版本相关的commit信息。在系统进行更新时，通过新旧系统对应的commit信息获取新旧系统版本的增量差异，并获取该增量差异，完成下载更新，并更新系统的commit信息。如图3所示，对象仓库存储了每一个版本的commit信息，当前旧版本是基于commit n，在进行原子化更新时，通过比对commit n和升级版本也即新版本的commit n+1的差异，增量更新当前旧版本，同时更新commit 信息。更新过程中若发生错误，系统将回滚至commit n对应的旧版本，若不发生错误，则升级至commit n+1对应的升级版本。

[0082] 以图4为例，为本发明的某一实施例的原子化升级中所涉及的文件版本更新示意图：在版本1和版本2之间，文件A与文件C已被修改。当开发人员提取版本2时，会收到一个含有A1和C1的签名压缩补丁，包含A和A1之间的差异以及C和C1之间的差异。然后只读机制将生成一个包含文件A副本的新目录，并应用此前生成的压缩补丁将文件A的版本更新到A1。对C进行同样的操作，使用压缩补丁将其版本更新为C1。文件B没有改动，则可以直接复用。
同理，在版本2和版本3之间，应用C1和C2的差异，将文件C1升级到C2；版本4基于版本3将文件A1升级到A2，文件B升级到B1；版本5基于版本4将B1升级到B2，将C2升级到C3。

[0083] 以上步骤会在不可变基础设施监控下执行，然后通过安全可信管理平台检查更新后的签名是否与压缩补丁中收到的签名匹配。若两个签名不匹配，只读机制将放弃更新并回滚到文件A和文件C的状态；若两个签名匹配，只读机制则会将更新标记为成功，并在设备重新启动时使用。只读机制通过使用副本和更新两个步骤，在出现电源故障时，确保操作系统使用文件A或A1以及文件C或C1启动。

[0084] 在以上原子化升级过程中，不可变基础设施会实时监控系统关键文件的状态，若发现有非法更新，将及时预警，并阻止更新，通过以下两个案例进行说明：

[0085] 案例1，如图5所示，当开发人员正常安装或更新软件包，触发原子化升级后，会生成此次的升级日志，然后只读机制（也即图5中的“不可变基础设施监控”）会生成新的文件系统树，对应一个新的系统版本，以及版本号、版本校验码并提交给只读机制用于后续校验（对应图5中的“新版本信息提交”）。不可变基础设施监控此过程，并通过安全可信管理平台比对版本号是否符合特定要求（即图5中“版本号是否合法”）、版本校验码是否与新版本匹配，以及升级日志中涉及的文件或目录是否符合可信要求。当判断为可信操作后，将正常进行系统版本的原子化更新升级；若检测到版本号不符合要求或者版本校验码与新的系统版本不匹配或升级日志不符合要求，则提醒异常并及时向开发人员预警并停止更新。

[0086] 案例2，如图6所示：当涉及到系统关键文件时，如攻击者想要通过安装/更新软件包的方式修改宿主机系统关键文件，基于只读机制的不可变基础设施监控会在升级日志中将其操作详细的记录下来，包括安装了哪些软件包、修改了哪些文件或目录，当该日志提交（对应图6中“新版本信息提交”）给安全可信管理平台后，检测到此次对系统关键文件进行了修改，首先会自动判定版本号是否合法、校验码是否匹配、升级日志是否符合要求，然后发出预警信息，告知开发人员有系统关键文件将被更改，如果开发人员不知晓，则阻止系统更新，仅在开发人员知晓的情况下进行系统版本的原子化更新并在更新状态完成后上报，从而达到了加固容器使用安全和安全防护预警的效果。

[0087] 本发明提供的基于只读机制的文件系统安全加固方法，在文件系统层面通过不可变基础设施来为容器使用提供安全防护，通过文件系统只读、系统原子化升级和升级安全预警实现了加固容器的使用安全。

[0088] 虽然本发明已利用上述较佳实施例进行说明，然其并非用以限定本发明的保护范围，任何本领域技术人员在不脱离本发明的精神和范围之内，相对上述实施例进行各种变动与修改仍属本发明所保护的范围，因此本发明的保护范围以权利要求书所界定的为准。