|
3.2 验证策略
对被执行 ELF 文件签名值的验证是根据"系统验证级别"和该文件的 "文件验证级别" 二者进行的。"文件验证级别" 是为单个文件设置的验证级别，共分为 3 个级别，分别由 0~2 表示。"文件验证级别"保存在每个文件的 inode 节点标志中，系统管理员可以根据需要设置文件的验证级别
"系统验证级别" 分为四级，分别由 0~3 表示。"系统验证级别" 通过 PROC 文件系统来进行控制，可以由管理员根据需要进行设置。
3.3 验证算法
当用户请求执行某个 ELF 文件时，系统将根据图 3-2 所示的流程来判断如何验证该文件的签名值。为了提高系统效率，我们将分别为已验证过 "不完全签名值" 和 "完全签名值" 的 ELF 文件维护相应的缓存，当再次请求执行这些文件时，就可以不必重复验证其签名值了。
 图 3-2：系统级签名值验证机制
图 3-2 中，"验证不完全签名值" 和 "验证完全签名值" 两项都是整个验证过程的重要步骤。签名值的验证与签名值的生成相对应，验证时首先要根据相应的数据通过 3 式计算出摘要值（h′part 或 h′comp），然后再使用签名者的公钥（PKsign）通过 ○4 式解密相应的签名值，得到的对应的摘要值（h′′part或h′′comp）。最后比较 h′和h′′是否完全一致，一致则验证通过，不一致则验证失败。
3.4 公钥管理
在解密签名数据时，需要用到签名者的证书公钥。由于可能存在多个签名者签发的代码，因此也就存在多个签名者的证书。为了节省系统开销，尽量减小对系统性能的影响，我们必须高效地管理这些证书公钥。为此，我们在系统核心空间中维护了一个信任公钥链表，所有被信任者的公钥都将被放在该公钥链表中。当系统验证代码的签名值时，就可以直接从公钥链表中取得相应的公钥。如果公钥链表中没有相应的公钥，则表示该代码的签名者不被信任，因而验证失败。系统中的被信任公钥是可配置的，系统在启动时将根据配置文件自动初始化核心公钥链表，系统管理员也可以随时对其刷新或者修改。
3.5 软件结构
本机制的实现主要包括用户空间的签名验证工具和核心空间的签名验证机制模块两个部分。其中，用户空间的签名验证工具是本机制的辅助工具，其主要功能是对 ELF 文件进行签名和设置，同时也可对 ELF 文件的签名值进行验证，在此不再赘述；核心空间的签名验证机制模块可以分为验证策略模块以及公钥管理模块。
|
