是否必须在由fail2ban读取的日志文件上设置一组特殊的权限？

Question

感谢 @roaima 分享链接在 CentOS 7 上安装fail2ban，这引导我走上解决这个问题的道路。

长话短说：

问题出在 SELinux 上。禁用它、更改其访问控制策略或更改存储日志文件的位置是（我发现）解决此问题的唯一方法。

解决方案：

一个快速而肮脏的修复和/或验证 SELinux 的问题是将 SELinux 的强制策略设置为“宽容”而不是“强制”。根据提供的解释这篇红帽帮助文章，将 SELinux 的执行策略设置为“许可”可以有效地禁用任何访问控制策略的执行。因此，如果 SELinux 访问策略是进程无法访问日志文件的原因fail2ban-server，禁用它应该可以让您了解 SELinux 是否是问题所在。这可以通过执行类似于以下操作的操作来完成：

[root@kaleb-desktop ~]# sestatus | grep "Current mode"
Current mode:                   enforcing
[root@kaleb-desktop ~]# setenforce 0
[root@kaleb-desktop ~]# sestatus | grep "Current mode"
Current mode:                   permissive
[root@kaleb-desktop ~]#

现在，如果您发现自己处于与我类似的情况，并且执行上述操作突然可以fail2ban访问您想要的日志文件，那么您很幸运。如果不是，那么不幸的是，您的问题可能是其他问题。如果您不喜欢保留 SELinux，我想上述方法已经足够了。然而，我并不一定想完全摆脱 SELinux。

如果您深入研究系统审核日志，您会发现 SELinux 实际上为您提供了更永久的问题解决方案。运行sealert -l "*"（我必须在 Fedora 38 系统上手动安装）将输出类似以下内容的内容：

SELinux is preventing fail2ban-server from open access on the file /tmp/testing.log.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that fail2ban-server should be allowed open access on the testing.log file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'fail2ban-server' --raw | audit2allow -M my-fail2banserver
# semodule -X 300 -i my-fail2banserver.pp

如输出中所述，建议的解决方案是创建一个可以应用于现有策略之上的本地策略模块。但是，正如 @roaima 共享链接的接受解决方案中所指出的，该策略可能会被未来的软件包更新覆盖selinux-policy。

因此，最终、最永久的解决方案是将日志移动到现有 SELinux 访问控制策略满意的目录。就我而言，我能够将日志移动到/var/logSELinux 似乎满意的子目录中。 YMMV。

我还想提一下，journalctl -lfu fail2ban我的系统上的输出并未反映@roaima 共享链接的输出。这个问题是 8 年前提出的，所以显然在记录方式方面可能发生了很多变化，所以请注意这一点。

很抱歉啰嗦，但我很高兴有这个机会深入研究我以前不理解的东西，并从另一方面得到更好的理解。我希望这个解释可以帮助处于类似情况的其他人！

Answer 1

感谢 @roaima 分享链接在 CentOS 7 上安装fail2ban，这引导我走上解决这个问题的道路。

长话短说：

问题出在 SELinux 上。禁用它、更改其访问控制策略或更改存储日志文件的位置是（我发现）解决此问题的唯一方法。

解决方案：

一个快速而肮脏的修复和/或验证 SELinux 的问题是将 SELinux 的强制策略设置为“宽容”而不是“强制”。根据提供的解释这篇红帽帮助文章，将 SELinux 的执行策略设置为“许可”可以有效地禁用任何访问控制策略的执行。因此，如果 SELinux 访问策略是进程无法访问日志文件的原因fail2ban-server，禁用它应该可以让您了解 SELinux 是否是问题所在。这可以通过执行类似于以下操作的操作来完成：

[root@kaleb-desktop ~]# sestatus | grep "Current mode"
Current mode:                   enforcing
[root@kaleb-desktop ~]# setenforce 0
[root@kaleb-desktop ~]# sestatus | grep "Current mode"
Current mode:                   permissive
[root@kaleb-desktop ~]#

现在，如果您发现自己处于与我类似的情况，并且执行上述操作突然可以fail2ban访问您想要的日志文件，那么您很幸运。如果不是，那么不幸的是，您的问题可能是其他问题。如果您不喜欢保留 SELinux，我想上述方法已经足够了。然而，我并不一定想完全摆脱 SELinux。

如果您深入研究系统审核日志，您会发现 SELinux 实际上为您提供了更永久的问题解决方案。运行sealert -l "*"（我必须在 Fedora 38 系统上手动安装）将输出类似以下内容的内容：

SELinux is preventing fail2ban-server from open access on the file /tmp/testing.log.

*****  Plugin catchall (100. confidence) suggests   **************************

If you believe that fail2ban-server should be allowed open access on the testing.log file by default.
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c 'fail2ban-server' --raw | audit2allow -M my-fail2banserver
# semodule -X 300 -i my-fail2banserver.pp

如输出中所述，建议的解决方案是创建一个可以应用于现有策略之上的本地策略模块。但是，正如 @roaima 共享链接的接受解决方案中所指出的，该策略可能会被未来的软件包更新覆盖selinux-policy。

因此，最终、最永久的解决方案是将日志移动到现有 SELinux 访问控制策略满意的目录。就我而言，我能够将日志移动到/var/logSELinux 似乎满意的子目录中。 YMMV。

我还想提一下，journalctl -lfu fail2ban我的系统上的输出并未反映@roaima 共享链接的输出。这个问题是 8 年前提出的，所以显然在记录方式方面可能发生了很多变化，所以请注意这一点。

很抱歉啰嗦，但我很高兴有这个机会深入研究我以前不理解的东西，并从另一方面得到更好的理解。我希望这个解释可以帮助处于类似情况的其他人！

是否必须在由fail2ban读取的日志文件上设置一组特殊的权限？

答案1

长话短说：

解决方案：

相关内容