当audit2allow建议restorecon和一种类型的强制规则时,是否需要这两种缓解措施?

当audit2allow建议restorecon和一种类型的强制规则时,是否需要这两种缓解措施?

SELinux 是宽松模式,有助于避免过渡到新的 RHEL7 服务器部署期间出现操作问题。虽然一些 SELinux 问题相当容易检查并解决,但我发现以下问题有些令人困惑。

AVC 如下:

type=AVC msg=audit(1533595368.668:140747): avc:  denied  { connectto } for  pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket

审计2为什么 说:

type=AVC msg=audit(1533595368.668:140747): avc:  denied  { connectto } for  pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket

        Was caused by:
                Missing type enforcement (TE) allow rule.

                You can use audit2allow to generate a loadable module to allow this access.

Audit2allow 说:

#============= postfix_postdrop_t ==============

#!!!! The file '/var/spool/postfix/public/pickup' is mislabeled on your system. 
#!!!! Fix with $ restorecon -R -v /var/spool/postfix/public/pickup
allow postfix_postdrop_t unconfined_t:unix_stream_socket connectto;

该通知似乎暗示问题的某些部分应该通过运行以下命令来纠正:

# restorecon -R -v /var/spool/postfix/public/pickup
# ls -lZ /var/spool/postfix/public/pickup
srw-rw-rw-. postfix postfix unconfined_u:object_r:postfix_public_t:s0 /var/spool/postfix/public/pickup

然而,SELinux 审核记录的问题在完成后似乎没有改变,因此,显然还有更多工作要做。据推测,部分问题与审核有关:

allow postfix_postdrop_t unconfined_t:unix_stream_socket connectto;

像 postfix 这样完善的服务出现 SELinux 问题需要管理员干预,这似乎很奇怪。

解决该问题的途径可能是:

# echo 'type=AVC msg=audit(1533595368.668:140747): avc:  denied  { connectto } for  pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket' \
  | audit2allow -M local_postfix_pickup
# semodule -i local_postfix_pickup.pp

也就是说,在没有更好地理解为什么这样的改变应该被认为是合法的情况下,简单地采取措施来消除审计问题似乎是不明智的。

这真的是一个标签问题,还是只是缺少“允许”的副作用,并且,任何人都可以评论这是否是管理员为了使后缀安装顺利运行而必须做出的合法的、预期的更改在 SELinux 下?

请不要建议关闭 SELinux。当然这是一个选择,但我宁愿学习如何保留它,并学习如何在出现这种性质的问题时辨别正确的行动方针。

注意:上述audit2allow -M ..semanage -i命令确实可以在不重新标记的情况下解决 SELinux 问题,但目前尚不清楚重新标记是否可以避免创建策略的需要。目前尚不清楚以这种方式解决问题是否符合预期和/或正常。

#============= postfix_postdrop_t ==============

#!!!! This avc is allowed in the current policy
allow postfix_postdrop_t unconfined_t:unix_stream_socket connectto;

答案1

事实上,自从restorecon使用以来,这些命令就不需要解决 SELinux 问题了:

# echo 'type=AVC msg=audit(1533595368.668:140747): avc:  denied  { connectto } for  pid=87400 comm="postdrop" path="/var/spool/postfix/public/pickup" scontext=system_u:system_r:postfix_postdrop_t:s0 tcontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 tclass=unix_stream_socket' \
  | audit2allow -M local_postfix_pickup
# semodule -i local_postfix_pickup.pp

以下是原因,希望能够在尝试解决 SELinux 审核问题时提供帮助。

  • 请注意缓解步骤之前的类型。在这种情况下:

    unix_stream_socket

    不幸的是,在运行命令ls -lZ /var/spool/postfix/public/pickup之前没有运行它restorecon,因为这有助于获得理解。

    提示:在进行更改之前查看 SELinux 上下文。

  • restorecon -R -v /var/spool/postfix/public/pickup注意运行后的 SELinux 类型:

    后缀_public_t

    值得注意的是,类型确实发生了变化。

    提示:当同时列出建议的restorecon命令和单个allow规则时,缓解建议不太可能是替代解决方案(两者之一都可以解决问题)。

  • 请注意,audit2allow输出已更改,建议的restorecon命令不再存在。

    audit2allow输出同时包含restorecon命令且只有一项rule更改时,在尝试使用 进行缓解后restorecon,问题很可能已得到解决。这里的关键是认识到ruleAVC 的显示不再相关,因为不再有任何理由制定关于不再使用的类型的规则。

    例如,在这种特定情况下,当该套接字现在具有 的顶部时,没有理由postfix_postdrop_t授予对 的访问权限。unix_stream_socketpostfix_public_t

在任何其他类似情况下,重要的是要记住 AVC 本身就是一个历史性事件。由于 AVC 是针对历史事件的,因此应该记住,如果替代解决方案中的细节不再与事件发生时系统的状态相同,则可能不需要旧问题的替代解决方案。换句话说,一旦使用该命令,当建议不再存在restorecon时,就不必期待“当前策略中允许”消息。restorecon

如果您仍然想知道不使用这两种缓解措施是否明智,请放心,如果实际上需要这两种缓解措施,则将来的审核事件将会发生。

不使用多种缓解措施实际上还有一个附带好处。请记住,SELinux 的全部目的是限制进程访问它们实际需要的东西。如果进行了不必要的类型强制更改,则可postfix_postdrop_t执行文件不再受限制访问unix_stream_socket与运行无关的其他资源postfix,并且合法的运行时约束postfix将被破坏。

这个问题更合适的标题可能是:“当audit2allow建议restorecon和一项规则更改时,是否需要这两种缓解措施?

相关内容