[hxtk]

Here's a short article on it by Dan "Mr. SELinux" Walsh himself [1].

To understand it, though, you need to understand at least a little bit about type enforcement, which is a somewhat steep learning curve to get over.

If you have nftables (replaces iptables, default back-end to firewalld in RHEL 8), you might consult /usr/share/doc/nftables/examples/secmark.nft but again, this requires some background on nftables (or iptables—they're both just front-ends to the kernel netfilter module) and are pretty similar.

However it's also worth noting that most one could also stand to learn a thing or two about netfilter if this is a topic they're interested in. For example, netfilter allows you to filter packets based on the user, group, or pid of the process.

I found this page [2] quite helpful, and especially the packet flow diagram contained within it.

[1]: https://www.linux.com/training-tutorials/using-selinux-and-i...

[2]: https://www.booleanworld.com/depth-guide-iptables-linux-fire...

[touisteur]

User, group and pid of the process are available through iptables. Really a great, simple way (in addition to other stuff) to compartmentalize complex applications. Shame it doesn't cross machine boundaries :-) (I know it's stupid but I like the simple user+group abstraction.

[hxtk]

Yeah, I'm not sure if it's clear but the iptables family and its replacement, nftables, are what I'm referring to when I say netfilter. iptables/nftables are userspace applications and netfilter is the underlying kernel module.

SELinux itself is not aware of pid/user/group.

[touisteur]

Sorry, of course. I meant the 'iptables' interface to netfilter can be enough for mere mortals that only use them once a year, and can filter on uid/gid/pid.

I'd like to find a real-world project to play with netfilter directly. Maybe when transitioning to 200GbE... Is it just for 'complex and numerous filtering rules' or are there other 'killer use cases' for using nftables directly?

[hxtk]

My understanding is that nftables and iptables+ip6tables+arptables+ebtables are for exactly the same set of use cases, with the latter being deprecated in favor of the former as the new replacement.

RHEL 8 uses the nftables back end for firewalld by default.

The main difference that I have noticed is that writing configuration files for nftables is considerably more ergonomic than the iptables files which are essentially just unstructured lists of iptables commands.

Generally things like UFW or firewalld are sufficient for host firewalls, but they fall short for routing applications where it is more appropriate to use nftables (or historically, iptables) directly.

Kubernetes and docker both currently use iptables for their routing and will likely migrate to nftables. If/then those projects migrate to nftables I suspect it would also solve the issue where docker port mappings have the ability to unilaterally punch holes in host firewalls, e.g., UFW, because under nftables, tables are just namespaces for chains (with configurable priority) while on iptables the different tables meant specific things and docker made decisions in a branch off of the PREROUTING chain in the nat table, which was encountered before the FORWARD or INPUT chains on the filter table. In this way nftables makes certain expressions more ergonomic than iptables.

[touisteur]

Oh thanks for taking the time to answer. Now I want to look into this even more.

[filterfish]

iptables has also been deprecated.

[hxtk]

The underlying netfilter has not been deprecated; the userspace application for managing it is just changing from the iptables (and ip6tables, ebtables, arptables, etc.) to nftables.