
134
|
第
9
章
序。可以将不需要的版本名称(通常是唯一的标签字符串、数字或散列
10
)列入黑名单,然
后将其并入部署系统的发布策略中。你还可以维护一份白名单,构建自动化流程,将已部
署的应用程序软件列入其中。
自行负责更新的特权或底层系统组件则更具挑战性。我们称其为
自更新
组件。例如,自更
新过程中,包管理守护程序会覆盖自身可执行文件,并重新运行;又如,固件镜像(如
BIOS
)会在其自身之上重新刷新替换镜像
,并强制重新启动。如果被恶意修改,它们可能
会主动阻止自己被更新。特定于硬件的实现需求增加了挑战性。对这类组件,也需要设立
有效的回滚控制机制,但是目标行为本身难以定义。为了更好地理解这个问题,让我们考
虑两个示例策略及其缺陷。
允许随意回滚
此方案不安全,原因是任何提示执行回滚的因素都可能重新引入已知的安全漏洞。漏洞
越老或越明显,市面上就越有可能存在稳定、武器化的漏洞利用程序。
禁止回滚
此解决方案消除了返回到已知稳定状态的路径,只允许前进到更新的状态。这种方法是
不可靠的,因为如果更新引入了一个缺陷,就无法再回滚到上一个已知的良好版本。这
种方法隐式地要求构建系统生成新的版本,借此可以向前滚动,从而为构建和发布工程
基础设施添加时间和可避免的依赖关系。
除上述两种极端方法外,还有许多考虑了许多实用权衡的替代方案,列举如下:
•
使用拒绝列表;
•
使用安全版本号(
security
version numbe, SVN
)和可接受的最低安全版本号(
minimum
acceptable security version ...