MAC and DAC – core security concepts

Arch Linux just announced that they are going to remove tcp_wrapper support. This is, I think, a good idea, since iptables can cover the security issues that tcp_wrappers does, and cover them in a better way.
In the ensuing discussion I supported the removal of tcp_wrappers and I called tcp_wrappers a Discretionary Access Control (DAC) system. This raised some questions about what a MAC and DAC is. So here is a simple explanation.
Primarily a MAC (Mandatory access system) is a system where all access to a medium is restricted, and then some things are made available. So a MAC is basically a whitelist.
A DAC is a blacklist. So it allows access to everything, but restricts things one at a time.
DAC = Allows all and restrict some
MAC = Restrict all and allows some
tcp_wrappers is a DAC in that it only covers a subset of the security scope. As an application authentication layer it only applies to select network applications. One could argue that from another perspective that tcp_wrappers can act as a MAC because it can use a catch all. I will argue that it is still a DAC because it only secures of subset of the network application scope.
For a final example, this would be a DAC setup in iptables:
-A INPUT -p tcp –dport 22 -j REJECT
-A INPUT -p tcp –dport 80 -j REJECT
So only ports 22 and 80 are blocked.
A MAC setup looks like this in iptables:
-A INPUT -p tcp –dport 22 -j ACCEPT
-A INPUT -p tcp –dport 80 -j ACCEPT
So this setup has a catchall reject, to block everything and then open up a few things.
Normally we think of SELinux as a MAC, but it is more accurate to think of it as an application layer system that can be set up in a MAC fasion, but even the default SELinux setup in Red Hat is still, technically a DAC because it only covers targeted applications. Of course the “strict” SELinux policy that the NSA developed is a MAC.
I hope this helps clear up the difference for some people on how these work!

One response to this post.

  1. I disagree. There are some things TCP wrappers handles that Netfilter does not. For example, other than resolving hostnames, Netfilter doesn’t touch DNS. So, there is no clean way to implement the PARANOID or UNKNOWN wildcards in Netfilter. As far as I know, you can’t implement the SPAWN command from TCP wrappers in Netfilter either. You could use something like “tail -f /var/log/syslog | awk …” to execute the command, but that’s a pretty bad hack.

    IMO, Arch Linux removing TCP wrappers completely from the operating system was a bad move. But, to each their own. Ff the argument is to remove it, because it hasn’t seen an update, better remove Vixie cron while you’re at it (heck, it doesn’t even support daylight savings). And fail2ban is a heavy, bloated, slow, and buggy replacement to use just for SSH.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: