Using SELinux and iptables Together (Linux.com) [LWN.net]

Over at Linux.com, Red Hat's Daniel J. Walsh digs into making SELinux and iptables play nicely together. It's a rather technical look at generating rules for iptables and writing SELinux policies to support the following use case: "I finally came upon a couple of use cases where I could write some simple rules and policy to further secure my laptop. I wanted to write policy to prevent all confined domains that are started at boot (system domains) from talking to the external network, and allow all domains started by my login process (user domains) to talk to both the internal and external networks. The idea here is I do not want processes like avahi, or sssd, or sshd or any other process that gets started at boot to be listening or affected by packets from an untrusted network. I want processes started by my login, like Firefox or my VPN to be able to talk to the network. If my vpn is shut down the system domains are off the network, while I can still use the Internet for browsing and email."

(Log in to post comments)

Second system effect?

Posted Mar 18, 2011 0:35 UTC (Fri) by Pc5Y9sbv (guest, #41328) [Link]

This approach seems to trivialize iptables a bit... just marking packets with an SELinux type.

Having looked into the use of these mechanisms for designing compartmentalized network appliances in recent years, I would have liked several features which I could access from one coherent policy language:

1. Ability to match context(s) of sending process when deciding how to handle packets in iptables, like other source-based rules. This is akin to exposing process uid now.

2. Ability to match context(s) of destination processes when deciding how to handle packets, like other destination-based rules. This is akin to labeling under the assumption of certain context/label access rules that will be enforced on that label, but lets the policy author think naturally about "who" as the destination pattern, symmetric to the source patterns.

3. Ability to match context(s) of listener processes to control who can open a local port for listening, since this can cause DoS even if all the traffic is filtered from the unauthorized party already. This is like labeling and assuming context/label access rules, but merged with the rest of the network policies rather than hidden off in a separate corner of the system.

I say "context(s)" above, because I really think this should be possible from the iptables standpoint whether using SELinux or POSIX context models. I would prefer iptables as the coherent policy language, because it is a much more pragmatic model for complex allow/deny filter chains on a variety of criteria. Also, the desired context-based matching rules are not just allow/deny but also the other iptables tables and chains such as for NAT and mangling.

Heck, I'd like a replacement for the SELinux policy core with something derived from iptables, mapping verbs to packets, and mapping processes and resources to sources and destinations... but that's another topic entirely!