The new "firewall" in Leopard is called
socketfilterfw, but as far as I can tell it doesn't actually do any packet filtering, which is how
ipfw and classic packet filtering firewalls work. Instead, it restricts the ability of programs to "bind" a port so they can receive all traffic for that port. This discrimination is not novel -- UNIX systems (including Mac OS X) will not allow any program to bind ports 0-1023 unless they're running as
root (UID 0). Normal users get an error when they attempt to take over low ports like this.
In recent years, many operating systems have made adjustments to this restriction, in an attempt to make permissions more granular. Apple, however, has added an entirely different (and much more sophisticated) test to the process of binding a port: does
socketfilterfw trust it?
socketfilterfw can even cryptographically 'seal' a binary (program), to make sure that if it is changed in the future, it automatically loses its authorization to listen on the network. Unfortunately, Apple seems to have gotten a bit carried away, and signed some tools that are as likely to be used by crackers who have just broken into a system as legitimate Mac users (
netcat, I'm looking at you)
socketfilterfw allows the request, the port is bound and the program receives traffic that reaches the port; if
socketfilterfw denies the request, the port is not bound to the requesting program, and it doesn't get any traffic. Ironically, this is very much more like a Windows firewall (e.g., ZoneAlarm), of restricting and allowing individual applications, rather than working at a network level that has little or nothing to do with individual programs.
Anyway, here's the help message for
socketfilterfw. Note the reference to
firewallapp, which does not exist on my system. Presumably it is an unreleased CLI tool to manage the firewall, like the
ipfw command manges the kernel firewall, or
iptables on Linux. Note that the FreeBSD-derived
ipfw is still available in Mac OS X Leopard (user), but not activated or used by the system -- it just passes all traffic through unless manually configured. On the other hand, Mac OS X Leopard Server's Server Admin (used in Advanced mode, but unavailable in favor of Server Preferences in Standard mode) still uses
ipfw. Over at Securosis, I'm working on an example
ipfw ruleset to get people dissatisfied with
socketfilterfw started, but before we post any rules, we need to decide upon a suitable (easy) way for people to use them without delving into writing custom
rc boot scripts.
$ sudo /usr/libexec/ApplicationFirewall/socketfilterfw -h
usage: /usr/libexec/ApplicationFirewall/socketfilterfw [-c] [-w] [-d] [-l] [-T] [-U] [-B] [-L] [-a listen or accept] [-s file to sign] [-v file to verify] [-p pid to write]
firewallapp is used to control Application Firewall socket filter.
The command takes the following options that are evaluated in order,
and several options may be combined:
-h display this help and exit
-t app set trusted app, e.g. -t app1 app2 app3
-i dump socket filter internal data info
-d turn on debugging
-l do logging and run in daemon mode
-k kill daemon
-a ask when listen or accept, ask "accept" or ask "listen"
-s file sign file
-v file verify file
-c check file
sudo /usr/libexec/ApplicationFirewall/socketfilterfw -d dumps out a list of allowed programs; there's some other junk in the output that looks like the signatures checked against the binaries, and a bunch of references to "ALF", which could stand for "Application Level Firewall".