主页 / server / 问题 / 1151583
Accepted
McLayn
Asked: 2024-01-16 18:45:54 +0800 CST

FAPolicyD 开销会减慢服务器速度

  • 772

我们有一台装有Alma Linux 9.3操作系统的服务器。默认情况下（以及当前所有类似 RHEL 的操作系统）它已fapolicyd启用。该服务器上还运行着一个应用程序服务器（WildFly/JBoss/Java）。部署的应用程序处理一些数据文件（由用户提交），并且在标准情况下工作正常。

然而目前，有一段时间应用程序需要每分钟处理 1000 个左右的文件。在这种情况下，fapolicyd开销占用了约 15% 的 CPU，我们认为该开销过高。

我在互联网上找不到有类似问题的人。

fapolicyd我也很惊讶ServerFault 上没有标签。

问题：

  • 有没有一种方法可以优化fapolicyd配置，以便它可以更快地决定是允许还是拒绝文件访问？
    • 我想到的一件事是自定义规则的排序。
    • 也许使用通配符与使用文字规则。
  • 有什么提示如何评估fapolicyd对我们来说有多重要吗？
    • 我们是否可以将其关闭，或者尽管开销巨大，但让它运行是否确实是一个好主意。
    • 其他发行版是否也使用类似的东西fapolicyd，或者它是否“只是额外的安全性”就SELinux足够了。（我知道它们不一样。）

资料来源：

security

1 个回答

  1. Best Answer

    允许列出已执行的程序是最有效的安全功能之一。如果没有它，受损的用户帐户就可以执行任何任意有效负载。或者用户将不应该安装的程序安装到其主目录中。尽管它是一项可选功能，您可以决定启用或不启用。

    检查所有此类文件系统调用会对性能造成影响。尽管可以通过优化规则和数据库来最小化开销。

    从用户的角度衡量性能是否可以接受。以响应时间为中心的目标，例如“99.9% 的应用程序 API 调用将在 1 秒内完成”，将检测到真正的问题，而不仅仅是资源利用率的趋势。

    首先，了解 fapolicyd 的一些背景，请注意README中的性能介绍：

    表现

    当程序打开文件或调用 execve 时，该线程必须等待 fapolicyd 做出决定。为了做出决定，fapolicyd 必须查找有关进程和正在访问的文件的信息。fapolicyd 的每个系统调用都会降低系统速度。

    为了加快速度，fapolicyd 缓存它查找的所有内容，以便后续访问使用缓存，而不是从头开始查找。但缓存就这么大。不过，你可以控制它。您可以增大主题和客体缓存。当程序结束时，它将像这样输出一些性能统计数据到 /var/log/fapolicyd-access.log 或屏幕中：

    Permissive: false
q_size: 640
Inter-thread max queue depth 7
Allowed accesses: 70397
Denied accesses: 4
Trust database max pages: 14848
Trust database pages in use: 10792 (72%)

Subject cache size: 1549
Subject slots in use: 369 (23%)
Subject hits: 70032
Subject misses: 455
Subject evictions: 86 (0%)

Object cache size: 8191
Object slots in use: 6936 (84%)
Object hits: 63465
Object misses: 17964
Object evictions: 11028 (17%)

    在此报告中，您可以看到内部请求队列最大为 7。这意味着守护程序最多有 7 个线程/进程在等待。这表明它得到了一些备份，但处理请求的速度非常快。如果这个数字很大，比如超过 200，那么可能需要增加 q_size。请注意，如果超过 1015 个，则可能需要告诉 systemd 允许超过 1024 个描述符。在 fapolicyd.service 文件中，您需要添加 LimitNOFILE=16384 或大于队列的某个数字。

    另一个值得关注的统计数据是点击率与驱逐率。当请求无处放置信息时，它必须逐出某些内容以腾出空间。这是通过 LRU 缓存完成的，它自然地确定哪些内容未被使用，并使其内存可供重复使用。

    上述统计中，主题命中率为95%。对象缓存就没那么幸运了。为此，我们的命中率为 79%。这仍然很好，但还可以更好。这表明对于该系统上的工作负载，缓存可能会更大一些。如果用于缓存大小的数字是素数，则与具有公分母的情况相比，由于冲突而导致的缓存改动会更少。您可能考虑的缓存大小的一些素数是：1021、1549、2039、4099、6143、8191、10243、12281、16381、20483、24571、28669、32687、40961、49157、57347、65353、等等

    另外，应该提到的是，策略中的规则越多，它需要迭代的规则就越多才能做出决定。至于系统性能影响，这很大程度上取决于工作负载。对于典型的桌面场景，您不会注意到它正在运行。在短时间内打开大量随机文件的系统会产生更大的影响。

    另一个可能影响性能的配置选项是完整性设置。如果将其设置为 sha256，则对象缓存中的每次未命中都会导致对正在访问的文件计算哈希值。一种权衡是使用大小检查而不是 sha256。这并不安全，但如果性能有问题，这是一个选择。

    do_stat_report = 1在 config 中启用统计报告，然后重新启动 fapolicyd（如果最近没有）。分析/var/log/fapolicyd-access.log 并记录哪些 PID 打开哪些文件的模式。

    注意“命中”与“未命中”的比率。命中率越高越好，访问内存数据库比文件系统访问和处理要快得多。增加obj_cache_size系统同时拥有的文件数量的配置。可能的上限是数据文件系统中已使用的 inode 数量（如df -i输出所示）。这可能过多，但如果您有足够的内存，为什么不缓存几十万个条目。

    检查 fapolicyd.conf 中的配置。除或integrity之外的值将计算校验和并具有开销。特别是如果您在处理新文件时出现大量失误，这可能会占用大量 CPU。应该大于访问报告上的“最大队列深度”，但是我怀疑是否需要增加队列大小。nonesizeq_size

    检查规则，在来自rules.d的compiled.rules中。RHEL 和 Fedora 从 rpm 填充可信文件，不允许执行未知文件，不允许 ld.so 技巧，并允许大多数打开。如果您确实修改规则，请考虑在打开的系统调用等待时执行更多操作对性能的影响。

    与往常一样，您可以在故障排除时分析到底发生了什么。 perf top将打印 CPU 上的功能，并且在安装了 debuginfo 时效果更好。bcc-tools 包有一些简洁的脚本：opensnoop 和 execsnoop 来实时列出 open 和 exeve 调用。

    最终，您决定采取哪些控制措施以仅允许执行未经授权的程序。在 exec 调用中立即允许列表，就像 fapolicyd 一样，当然非常强大。一个不太全面的替代方案可能是限制 shell 访问：不允许人们交互 shell，并锁定主目录的权限。或者，如果数据文件系统根本不应该有任何程序，请考虑以 noexec 方式安装它。良好的安全审核不会将清单视为一成不变，而是会列出适当的替代控制措施及其原因。

    • 1

相关问题