免责声明：我远非 SELinux 或 AppArmor 方面的专家，因此您需要自己检查我所说的一切。

我认为有一种方法可以让 SELinux 和 IPTables 一起工作。SELinux 可以使用标签标记数据包，该标签指示适用于数据包的 SELinux 上下文/来源/出处。然后，您可以编写检查此标记的 IPTables 规则，以根据此标记的值应用不同的防火墙策略。这似乎是一种执行更细粒度控制的潜在方式，例如，强制特定应用程序只能与某个端口号或协议通信。参考资料：让 SELinux 和 IPTables 相互交谈，关于此的文章和关于 LWN 的相应讨论，以及secmark 的背景，数据包标记子系统。

对于 AppArmor，据我所知，目前不支持此功能。有一个请求此功能的错误跟踪器条目。

我相信 Systrace 已经内置了对这种更细粒度的控制的支持。

在上面添加个人经验说明 - 将 selinux 与 iptables 结合使用会使策略和您的 iptables 看起来非常复杂和令人费解。这是复杂性权衡必须真正值得麻烦的情况之一 - 除非您正在确保正确的数据包标签意味着生死攸关的军事设施，否则我不会推荐它。

SELinux 确实提供了一些与 iptables 无关的基本端口/协议标签。例如，如果您运行semanage port -l它，它将为您提供目标策略中定义的所有端口的列表。您可以使用它来限制 SELinux 域可以在哪些端口上进行通信。例如，您可以编写一个策略，声明myapp_t只能绑定到myapp_port_t和连接到http_port_t. 这已经很不错了——如果攻击者设法利用该应用程序，他们将无法绑定到任何其他端口或连接到除 80/tcp 之外的任何其他端口（例如，这将阻止连接到 IRC 的尝试）。

如果你真的喜欢它，你可以进一步说——标记所有由myapp_port_tas创建的数据包，myapp_packet_t并将防火墙配置为仅传递myapp_packet_t到-d 10.10.10.1 --dport 443. 然后，如果攻击者设法利用该应用程序，他们将只能在端口 443 上与 10.10.10.1 通信，而其他应用程序（例如浏览器）则不会受到限制。

话虽如此，虽然理论上它很棒，但实际上应用程序产生的数据包流量比端口 443 上的一个传出 tcp 多得多。应用程序需要执行 nslookups（因此您需要允许 myapp_packet_t udp 到端口 53），并且如果您的用户信息来自 ldap，它可能会产生 ldap 流量。结果，您的策略和 iptables 迅速膨胀成无法管理的庞然大物。我建议坚持基本的港口标签。:)