我们有几十个 Ubuntu 系统(从 8.04 到 9.40,台式机和服务器都只有串行控制台访问权限,我们希望在这些系统上运行修补版本的 glibc。
特别是,这是为了修复glibc 的解析器无法允许 OpenSSH 的 ssh 客户端等程序设置 AD 位;我们想做的事情的一般要点可在博客文章How to get OpenSSH to see DNSSEC AD flags on SSHFP lookups with glibc中找到。我们正在考虑进行更广泛的修改,将 AD 位支持添加到头文件中,以便我们可以编译标准 ssh 二进制文件,尽管这也需要替换 ssh 客户端。
所以我的问题是,进行更改、保持与 Ubuntu 的定期更新同步并将其分发到我们所有机器的最简单方法是什么?
我猜最好的办法可能是维护我们自己的 Ubuntu 源包副本,每次更新都更新我们的,适当地构建新版本,并通过设置一个位于包服务器列表中的服务器来分发它们每台机器。但是我对如何执行此操作的详细信息知之甚少,无法知道这是否是最佳选择。如果是,我想要一些关于设置细节的指针。
有些人可能想知道我为什么要这样做。有两个原因:
这个特性不会很快被添加到 glibc 中。它已经失踪了五年多,没有人对此表示任何关注;相反,他们说他们觉得添加该功能太危险了,因为更改的“高安全影响”,或者类似的事情。
我们有一项严格的政策,您不得通过 ssh 连接到未验证密钥的公司机器(即,我们使用“StrictHostKeyChecking yes”ssh 选项)。
我想避免在这里讨论上述任何一点。如果您想了解有关 glibc 维护者政策的更多信息,或者如果您不了解当您不遵循我们的安全政策时您所面临的攻击,请发布一个单独的问题,并通过电子邮件发送给我它的网址,我将从这里链接到它。
你想完全按照你的建议去做,并维护补丁包。建立一个 repo 非常简单,我只是使用 apt-ftparchive 来完成写出 Packages 文件的繁重工作。有一个 procmail 规则来监视 ubuntu-security-announce 列表,并警告您感兴趣的软件包的任何安全更新。如果您在获得一些乐趣之前从未构建过包,但如果您能够阅读文档,这并不是特别困难。
在您的一台内部服务器上设置自动存储库,并与 ubuntu 的版本同步。确保您的客户都没有从 ubuntu 添加“提议的更新”存储库,并自己注册(作为补丁的维护者),这样您就可以在实际更新之前提前提供您的版本。
将版本命名为子更新,所以它会“over” ubuntu 的版本,例如,当前版本是:
假设您的组织被称为 example,它应该是
2.9-4ubuntu6example1
. 您甚至可以 PGP 签署您的档案,以获得额外的安全性。不需要 SSH,您可以使用PackageKit + PolicyKit 让用户更新它而不给他们 root 访问权限(假设您有那么严格)。
作为旁注,我敢打赌补丁不被接受的原因是因为 Ulrich Drepper,他几乎拒绝了“他不信任”的人的每个补丁。很快,Debian 将切换到 eglibc,它有更友好的开发人员,他们考虑添加任何补丁。