运行时验证执行代码

关键词：可信计算，主动防御，运行时防护，入侵检测，应用程序白名单

背景

有人说Linux比Windowns安全，发展至今，这个论断是错误的。Win经过多年的安全反复折磨，Win11自身的安全特性加上自带的各种安全工具已经可以保证在个人桌面上足够安全。Linux本身存在各种安全机制和安全工具，但由于以下各种原因，其安全现状很不理想。

Linux使用场景的多样化。有云环境、IOT环境、工业互联网环境等等。每种场景下，其安全威胁和要求相差很大，很难有统一的"安全银弹"。

在每种使用场景下，都会有对内核、系统组件的各种改动。且不管自己引入代码的安全威胁，很多人为了方便把为数不多的安全功能直接关闭、禁用。

缺乏专业的安全人员。很多中小公司都是运维人员兼职安全工作，安全问题频发。

专业知识的匮乏、没有针对自己场景的安全规划。不管什么安全问题，使用百度一搜，也不理解是否适合自己的场景，更分不清哪些是pr文章、哪些是自己可以利用的。举个例子：零信任比较火，大小公司都上零信任。

当前情况下，“蓝军”知识、人才还是比正向安全建设的多。加上圈子文化，宣传的单一化，形成漏洞、渗透、逆向等于安全的错误印象。

HIDS的缺点

在种种乱象之下，也形成了一些安全共识：账户及权限管理、修复漏洞、安全基线、最小攻击面、入侵检测、安全扫描、代码安全、数据（传输）加解密等等。其中主机入侵检测HIDS是重要的运行时安全检测工具，但是开发和运营一套HIDS需要不菲的成本，由于场景的多样化，使用HIDS不一定适合自己的实际场景。

HIDS是事后、事中检测和防御工具，属被动安全工具。

尽管有开源的HIDS工具，但不一定适合自己的场景，多数场景下都需要定制化开发，涉及到不少的开发量。

部署也需要一定的机器资源、网络资源。

部署后也要有相应的人员运营。数据分析、误报、漏报、应急响应都会让运营人员累的够呛，还没有成就感。

由于系统版本和开发人员的技能差异，HIDS实现上有不同的缺陷，如数据收集不全、资源使用过多，有的实现还比较容易绕过。

应用程序白名单

以上种种缺点，HIDS只适合于一定规模的公司。小公司不可能像大公司那样有清晰的划分、专业的团队，就需要有比较容易使用的安全工具解决大部分安全问题。而且对于IOT设备，由于不能集中管控，安全更加复杂。需要从另一个角度思考安全防护，验证执行代码的签名---应用程序白名单（NIST sp800-167）。应用程序白名单（本文中应用程序指可执行/so ELF文件、脚本、解释性程序、webshell等）：

不在白名单中的代码不允许执行。

很多恶意目的都是以可执行程序、so库、脚本程序、webshell等为载体完成。

也可阻止以执行代码为载体的漏洞利用。

应用程序白名单与 HIDS的比较

HIDS的检测规则是 "黑名单"规则， 应用程序白名单是"白名单"规则。

HIDS是检测，应用程序白名单是防御。

HIDS是收集数据---分析数据---告警。应用程序白名单是立即阻止破坏。

不在白名单中的恶意程序，即使已经感染机器，也不能运行造成破坏。

应用程序白名单也是解决当前威胁最严重---勒索软件的根本解决方案。

对各种恶意软件的变种、未知恶意软件、间谍软件、rootkit等，一(软)件防御。

强制访问控制MC介绍

MC是内核中实现应用程序白名单的强制访问控制，属可信计算的一部分，是实现主动防御的主体功能。

对一个Linux系统来说, 即使有漏洞，如果不运行，不与外界交互，也是安全的。基线完整的系统，随着与内外部的交互，就引入了各种安全问题。保证系统运行过程中的完整性，是保证安全的基础。保证系统中执行代码的完整性，是系统完整性的重要组成部分。MC验证 elf可执行程序、so库、脚本、解释性程序的签名，也就是说任何在应用层运行的代码都保证来源可信。

尽管Linux系统中有selinux、apparmor、smack等，但配置比较复杂，掌握使用比较困难，在很多场景下都是关闭的。而且都没有运行时验证执行代码。

MC设计和实现遵循以下原则：

简单。容易理解，实现简单、使用简单。在/proc文件系统中引入接口，规则配置类似iptable规则。这样就降低了运营人员的学习和使用难度。避免了selinux规则配置的复杂性。

高性能。不能消耗太多的资源， 而且资源消耗可视化：在/proc/kernel/mc下有MC系统消耗的cpu时间。测试来看，正常使用状态下，cpu消耗几乎忽略不计。



total_cost是MC系统花费的总时间，以jiffies为单位，换算成秒大约10.3秒,  占总时间的  1.7%。

不求功能全面。通过规划、定制规则，满足多数场景即可。现阶段主要面向IOT设备、自己可以安装内核的服务器、容器宿主机环境。

应用程序白名单既可以定义成应用程序的绝对路径，也可以是应用程序的标记以适应容器云场景。当前标记是应用程序的sha256sum值。

MC系统组成

打上补丁的内核。

目录/proc/sys/kernel/mc/下的接口。通过这些接口可以进行配置规则、查看策略，查看性能统计信息等等。

一些应用层工具，主要包含：一些签名的工具、 接收MC系统内核日志并进行动作的精灵进程。

解释类程序的配置规则格式。编译性程序不需要配置，强制验证签名

配置规则是向 /proc/sys/kernel/mc/set_interp_rule写入规则. 

规则格式如下：

ADD/DEL interp MAGIC/MIME/EPATH/*  [offset magic_word]/[mime_type VERIFY|SKIP]/[epath]...

动作  解释器路径  配置是[魔数/MIME/忽略路径]的关键字   相应配置的具体内容

ADD/DEL interp MAGIC [[offset magic_word] [offset magic_word] ... ]    //给解释器配置解释文件的魔数
ADD/DEL interp MIME  [mime_type VERIFY|SKIP]                           //给解释器配置解释文件的MIME类型
ADD/DEL interp EPATH [epath]                                           //给解释器配置忽略的文件或者路径 
ADD/DEL interp DEFAULT [ACCEPT|REJECT]         //给解释器配置默认策略
ADD/DEL interp *                                   //强制验证解释器解释、打开的文件

上面配置命令里大写的是关键字，关键字不区分大小写，但一般大写以示区别。

MC相关接口和工具

/proc/sys/kernel/mc 目录、 /etc/mc配置文件目录、 /usr/local/bin/mc-*工具程序、日志文件。

每部分的具体功能和使用请参考 https://github.com/z789/mc-rpm。

MC的使用要求

要求使用者充分了解自己的系统，充分了解系统上运行的软件。哪些可以加入白名单，哪些不能，哪些是信任的软件，哪些是不信任的软件。

在充分了解自己场景的基础上，能设计适合自己场景的规则，系统更安全且消耗更少的资源。

优先配置MAGIC规则，其次是MIME规则，最后是忽略路径EPATH规则。 

EPATH尽量少使用，如果使用，尽量精确到文件。如果能设计适合自己的MIME系统，完全可以不用EPATH。

最后

网络安全已经是国家安全的重要组成部分，每一个公民都应尽自己的义务维护国家安全。可信计算作为安全基础理论，包含丰富的内容。而应用程序白名单是不依赖任何硬件特性，比较容易理解和使用，业界急需，且能解决大部分安全问题的机制。随着IT的发展，安全也会出现新的问题，愿与有志中国网络安全建设的人员共同讨论、进步。

审核编辑：刘清