SEPostgreSQL 评论 BWPUG

作为 2009-11 CommitFest 的一部分，巴尔的摩/华盛顿 PostgreSQL 用户组 举办了一场为期两小时的会议，讨论了 OmniTI 处 SEPostgreSQL 补丁（过去和现在）的状态。参加者包括 PostgreSQL 常客罗伯特·特里特、斯蒂芬·弗罗斯特、格雷格·史密斯（2ndQuadrant）和 Hubert “Depesz” Lubaczewski 以及 Joshua Brindle（Tresys）、David Quigley（NSA）和 Brian Dunavant（OmniTI）。PostgreSQL 社区关于这个功能的担忧的总体议程由格雷格提供，尽管有阶段性的离题（主要与 NFS4 开发的相似性），但我们还是对所有预定主题进行了初步讨论。

合并 SEPostgreSQL 的已知问题

此功能的用户群

此功能如何运作的示例似乎总是使用政府背景，例如标准的“基于安全级别过滤”。有零星的证据表明这样的客户存在，而且如果 Tresys 和 NSA 的这些人不知道他们，他们肯定不会参与其中。但这存在问题，因为这些客户不太可能讨论他们的需求、他们在做什么或是否在使用该软件。该补丁还可用于哪些其他应用程序？

罗伯特指出 OmniTI 定期为处理信用卡支付的应用程序（在电子商务领域非常常见）处理PCI 合规性，并且它具有类似的用户隔离和隐私问题。有一个甲骨文产品针对该市场。约书亚在白板上举了使用 SELinux 和 SEPostgreSQL 构建此类解决方案的示例，这既可行，也很匹配。罗伯特认为，当前针对 PCI 合规数据库的解决方案非常难以使用，因此做得更好并不难。他的观点基本上是“尽管我讨厌 SELinux，但如果它使我能够使用 PostgreSQL 而非我现在被迫为 PCI 使用的数据库，我会忍受它”。有关此方法最具价值的领域的具体详细信息，请参阅PCI 规范中的要求 7“实施严格的访问控制措施”。

另一种可能性是 ISP 空间。希望使用 Postgres 的 ISP 共有的一个抱怨是，他们必须为每个用户创建一个集群，它拥有自己指定的唯一端口和所有内容，因为单一集群内数据库之间存在太多安全漏洞，客户无法共享一个集群。SEPostgreSQL 是一种可改善该情况的潜在方法。在LAPP/SELinux 演示的第 24 页上有一个示例。

至于“是否有人已经在使用 SEPostgreSQL？”问题，情况似乎是出于安全目的而使用 SELinux 的国防部网站只在 RHEL 上认证过该方法，而没有认证过 Fedora。约书亚指出，如果目前针对 Fedora 的 SEPostgreSQL 软件包不再正式地在 RHEL 上由 RedHat 推出，他们的要求将被取消——这是目前阻止部署任何现成软件包的缺失部分。这种情况表明，在达到某个里程碑之前，要求的一个子集根本没有任何用处，而对于本例，RHEL 兼容性就是该里程碑。

安全专家审核

对于 PostgreSQL 社区来说，目前尚不清楚，KaiGai 实施的模型是否已接受过任何安全专家的审核，以评估它是否适合构建高安全性应用程序。不能认为数据库黑客具有自己实施此操作所需的专门知识。

Joshua 指出，多年来他一直亲自参与此类审查，安全社区的许多其他成员也一直参与，记录可参阅 SELinux 邮件存档。围绕SE-PostgreSQL 8.2.3-1.0 alpha 2007 早期展开的讨论很好地展示了这项工作可以追溯至何时。2007 年夏季，Greg 与 Joshua 就此事进行过探讨。去年，Joshua 在 pgsql-hackers 中留下了身影。尽管我们并未经常在我们的列表中看到他的踪迹，但他肯定没有就此离去。正如我们近期所见，Tresys 的 Chad Sellers 和 NSA 的 David Quigley 现在也跟踪着 PostgreSQL 的集成工作。KaiGai 在此所做的工作已经接受过该领域专家的严格审查，并将其反馈纳入其设计中，只可惜这项工作不在 PostgreSQL 列表中进行。

值得一提的是，SEPostgreSQL 正在接受数据库安全领域的研究人员的关注。一个例子是大卫·安在 UMD 发表的关于Oracle 标签安全 一文的最新论文，其中提到 SEPostgreSQL 是一个可能的先前实现。

现成的 SELinux 策略

我们有些担忧，担心 RedHat 花费了很长时间才为应用程序制定出一个有用的策略，担心产生一项对用户有用的 SEPostgreSQL 策略也需要类似的延迟。我们本地的 SELinux 专家对此并不担忧。SEPostgres 已于 2007 年实施到 Tresys 维护的标准SELinux 参考策略中，并且自那以后，它一直在不断维护，并在新的 Fedora 版本中向前发展。对于从事这一领域工作的人来说，这个问题在多年前就已经解决了。

SELinux 之外的工作

有一项担忧是，SEPostgres 的实施与 SELinux 联系较为紧密，可能无法与其他安全解决方案相集成。针对这一问题提出的最佳数据点是Trusted RUBIX。Trusted RUBIX 是我们可以与 SEPostgres 在核心层面展开竞争的另一款产品。Trusted RUBIX 使用最初添加到策略中的相同 SELinux 对象类型和权限，以支持 SEPostgreSQL。他们的文档展示了他们在 RDBMS 中如何使用 SELinux。在第 15 页中详细描述了他们使用的对象类型和权限。他们甚至实现了行级安全性（db_tuple 对象类型）。Trusted RUBIX 同时映射至 SELinux 和 Trusted Solaris，证明了使用专为 SEPostgreSQL 设计的策略的方法可以映射到另一种安全性实现中。此外，由于该处进行的部分工作基于 KaiGai 的 SEPostgreSQL，因此设计思想将作为一个部分回馈给他，帮助改善了其正在处理的模型。例如，参见SE-PostgreSQL 增强中的部分想法。

而且，SELinux 与 Linux 没有太大的关联，这也是事实。SELinux 的基本安全模型已经移植到 BSD 和 Darwin 上。约书亚和大卫都强调，这些端口非常简单；大部分代码保持不变，只需要与文件系统对象等进行交互的最低级别发生改变。这进一步支持了与 SELinux 关联的安全对象模型是一个合理的代码目标。

虽然在为另一个安全系统完成第二次实现之前，我们永远无法完全确定，但有证据表明 SEPostgres 将数据库对象映射到安全对象模型的方式足够通用，也可以处理其他安全实现，只要它们有一个合理的基于对象实现即可，这似乎是当前的常见方法。这篇主题的不错介绍文章是 美国国家安全局与 Sun 携手提升 Solaris 安全，描述了所有这些安全层的共同起源，它提到 PostgreSQL 也符合该结构。它还提到了 pgsql-hackers 列表中提到的一些建议备选方案，例如 AppArmor，并不适合安全行业其余部分的发展趋势。

其他挂钩实现的细节

在 Linux LSM 的情况下，每种逻辑操作/动作都有一个单独的挂钩接口，其中挂钩名称标识动作/操作，该挂钩接口的一组参数可能与决定允许操作/动作相关的输入集合完全相同。这些参数通常包括指向一个或多个对象数据结构的指针以及辅助参数（例如执行 chown 时的新的所有者值）。参考资料：1，2。

与 LSM 框架不同，X 服务器 XACE 框架 传递的是资源标识符，而不是直接的对象指针。

FreeBSD MAC 框架 提供的抽象性高于 LSM，但框架本身的开销比较大。

CERT 针对缺陷发布的公告

一个严重且非常合理的问题是，添加一个涉及如此多数据库安全相关部分的大量代码段将引入新缺陷，从本质上来说，这都是必须通过诸如 CERT 等渠道披露的安全问题。虽然这些通告可以清楚地说“仅会影响正在使用 selinux 集成的用户”，但仍然会计入 PostgreSQL 报告的总数。这个问题没有简单的解决办法；代码审核、小心谨慎的模块化和测试是唯一的防御措施。

PostgreSQL committer

很明显，我们需要一位合格的提交者对 SEPostgres 审查进行认真的审查，还有大量潜在的后续工作需要完成。目前看来，布鲁斯·莫米扬对此感兴趣，但前提是需要有一个明确的计划，解决社区担忧，并朝着达成设计共识的方向前进。BWPUG 所在地（本身位于美国正在进行的 SEPostgres 工作的中心位置附近）对于布鲁斯来说足够近，因此我们可以轻松安排一些面对面的时间，作为我们用户组的一部分来处理这件事，或许可以安排一个“SEPostgreSQL 日”或类似的活动。我们可以很容易地邀请本地安全供应商联系人，例如这次会议中访问的 Tresys 和 NSA 员工。我们还可以邀请已投入大量精力审查此补丁的罗伯特·哈斯，作为另一位我们可以邀请到此类活动中的相对本地人士。如何帮助为有兴趣参加此类设计研讨会的提交者资助差旅费是一件我们接下来会研究的事情。

未来的维护者

有一些担忧，即让 KaiGai Kohei 作为唯一的贡献者维护此补丁向前发展并不是理想的，特别是如果最终引入安全漏洞等对时间敏感的问题。在我们的会议上，一些常规 PostgreSQL 代码贡献者（斯蒂芬·弗罗斯特、格雷格·史密斯）正在考虑启动使用 SEPostgres 的项目，这可能会允许他们未来投入更多时间在这个角色上。这个领域显然需要更多帮助。

后续计划

概念验证/原型开发

很明显，除了“秘密许可”之外，还需要有人证明其他用例是可行的，但我们不会看到任何现实世界中的示例。最理想的做法是，可以通过一种方式让社区可以发布结果供审查。PCI 合规示例就是一个很好的可能性。斯蒂芬·弗罗斯特和罗伯特·特里特都有商业相关需求，这些需求可能使此类概念验证项目可行。主要问题似乎是通常出现的问题：寻找足够的人力或资金（后者总是能产生前者）。任何有类似兴趣的人士都应该联系他们和格雷格·史密斯，他正在尝试帮助跟踪所有这些活动并在社区内协调资源。

PostgreSQL 安全检查清理

斯蒂芬·弗罗斯特提出了最近的评论，指出很多 SEPostgres 问题是由于后端代码中模块化和数据隐藏问题的普遍存在，导致很多地方都分布着安全检查。他认为，这里的一些问题并非是 SEPostgres 特有的；SEPostgres 只是突出了这些检查分布有多分散。

缩小 SEPostgres 补丁集的规模及其对后端代码的侵入性的尝试似乎不太可能走得更远——我们已经接近有用的最小集合了。如果我们想要继续缩小它的规模并使 PostgreSQL 代码库更加适合于与安全框架进行干净而简单的合并，那么对底层代码进行全面检查似乎是一种富有成效的方法。这应该会缩减 SEPostgres 与后端代码相关的差异，从而降低合并代码的风险。

重新审视行级安全性

我们当地的专家们最想念的当前 SEPostgres 补丁中削减的功能是行级安全性。没有它，值得怀疑是否提交现有精简补丁真的能为他们所针对的用户群带来任何好处——即使是微不足道的“秘密许可”示例也需要它，而且许多真实世界的应用程序当然也是如此。导致这一领域被放弃的担忧

• 与 SQL 合规性的交互
• 旁路信息泄露
• 过度特定的 SELinux 代码

如果补丁可以更简单地连接到基本服务器中提供的行级安全性，就不会出现这些担忧。

未来的会议

这次短暂的会议汇聚了来自多个行业对该领域感兴趣的人员，非常富有成效，而未来计划周全并宣传更好的会议可能会更好。可能性包括

• 该领域的未来“SELinux PGday”
• 会议演讲（例如在 PGCon 2008 上的演讲）：PG East 2010？PGCon 2010？除了发表全文演讲，还可以进行关于补丁开发现状的快报。