$ sudo /opt/local/bin/port install db46
...
Error: db46 requires the Java for Mac OS X development headers.
Error: Download the Java Developer Package from:
Error: Target org.macports.configure returned: missing Java headers

The solution consists of creating symbolic link to the installed files:

sudo ln -s /Developer/SDKs/MacOSX10.6.sdk/System/Library/\
  Frameworks/JavaVM.framework/Versions/CurrentJDK/Headers \
  /System/Library/Frameworks/JavaVM.framework/\
  Versions/CurrentJDK/Headers

To disable Bonjour broadcasting, just add:

<string>-NoMulticastAdvertisements</string>

to the array in the ProgramArguments section in System/Library/LaunchDaemons/com.apple.mDNSResponder.plist:

...
        <key>ProgramArguments</key>
        <array>
            <string>/usr/sbin/mDNSResponder</string>
            <string>-launchd</string>
            <string>-NoMulticastAdvertisements</string>
        </array>
...

This has been reported and discussed in the following Apple support thread. In the end, the solution typically requires to uninstall Google Talk Video. The solution was found and reported by Snoop Dogg in that same thread.

Basically, the misbehaving process can be found by running sudo pmset -g log then looking for the process with the highest response time. In my case:

$ sudo pmset -g log
...
 * Domain: applicationresponse.timedout
 - Message: Kernel GoogleTalkPlugin com.apple.powermanagement.applicationrespons
e.timedout 30000 ms
 - Time: 9/2/09 12:42:47 AM GMT+02:00
 - Signature: GoogleTalkPlugin
 - UUID: AD1E9199-B66D-41CB-BF4F-590EF232DE79
 - Result: Noop - Response time (ms): 30000
...

In any case, these are good news and to me a proof that Chromium for Mac OS X keeps evolving at a fast pace and that it is making very good progress. As a consequence, a few days ago, I switched to Chromium as my main browser (also in Linux) and I must say it feels great so far.

PS: This post was written entirely under Chromium for Mac OS X. No crashes or any strange behavior were experienced.

For more than a month I’ve been tracking development of Chromium for Mac OS X. I’ve been building and testing Chromium for Mac OS X myself [1] and my general impression is that development pace is pretty fast. For example, yesterday, a mock Preferences dialog box was added. A few days ago, working support for draggable and dettachable tabs was also added (previously it was possible to detach a tab from a window but it was not possible to re-attach it to an existing window).

Overall, the Mac OS X port of Chromium is getting more and more usable and stable. I’m now able to use it for most browsing tasks. The look and feel matches perfectly Aqua but also resembles a lot its Windows counterpart. While it is true there are a few annoyances, like losing the focus on edit controls when switching tabs, or tabs crashing at times when executing a paste operation, they are getting fixed in each iteration. The browser feels extremely fast when compared to Firefox 3.0 and faster than Firefox 3.1, Safari or Safari 4 beta. Heavy and complex Web pages like Google Reader or Google Mail load almost instantly while still looking correct. Some Web pages get rendered slightly different from other browsers. As an example, Google Mail looks slightly different with bigger spacing between lines in the mail thread (main) view and also slightly smaller fonts, but these are very subtle differences that do not affect usability or readability.

I must confess I’m pretty impressed about Chromium. When Google disclosed Chrome and the initial availability for the Windows platform only I was very disappointed. I also thought that it’d take much longer to see a nearly-functional port for Mac OS X or Linux. But I was wrong. It is good to be wrong. Let’s hope the development pace keeps on the same levels

PS: By the way, this post was written entirely from Chromium in Mac OS X. The tab crashed a couple of times but WordPress has a nice auto-save feature that I really appreciate

[1] http://code.google.com/p/chromium/wiki/MacBuildInstructions

During the Pwn2Own contest, Safari was the first browser to fall, in the order of seconds, when put under attack by Charlie Miller. This has been reported in several places, like Pwn2Own 2009: Safari/MacBook falls in seconds, or Miller: Safari on Mac First to Fall During PWN2OWN Contest, or Miller Cracks Safari Within Seconds, Wins PWN2OWN Contest. For the second year in a row, Safari/MacBook has been the browser to fall under attack the first.

So, if you are a user of Mac OS X, be very careful when using Safari. These attacks so far require you to click on links specifically crafted to cause harm to your computer, which might allow the attacker to gain total control of your machine. Hence, the importance of never running with an account that has administrative privileges.

Someone pointed me to the FreeNX 0.7.3 announcement that contains the following excerpt:


Usermode and SUID Wrapper
==================

We are now very close to login directly with users and I also heard of a C program, which can be seamlessly put between nxclient and nxssh. So with client support we now have three alternatives:

1. Login as user via ssh and connect to server with ssh command on server again.
2. Login as user and use usermode to save all sessions locally for each user.
3. Use a SUID nx (not root!) wrapper to startup a new "trusted" session.

One is error prone, two is good, but looses the central structure, three is best of both worlds and with being suid nx also has the most advantages, however not the dreaded public key problems.

_Yes_, this means if you use the suid wrapper, you still need the nx user, but you can remove the public keys and it'll still work.

The SUID wrapper is a part from the work of the redesign and thanks goes to Alistair Riddoch from Google here.


By default, NoMachine’s NX nxserver requires nxclient to login via SSH into the remote machine as user nx. As nxserver is defined as the login shell, it is run by the sshd daemon. From there on, there is a dialogue between nxclient and nxserver where nxclient supplies the user credentials (username and password that were specified in the nxclient configuration). There is, in fact, a second authentication that is performed via another SSH session to 127.0.0.1 using nxclient’s supplied credentials. If this second authentication succeeds, the NX session is activated and accessible from the NX client.

This works well for remote servers that are shared by multiple users, as the nx user and its centralized approach makes it very easy to see how many sessions are currently running (or suspended), terminate them, etc. However, for machines that are not shared by multiple users, or in those cases where authentication mechanisms other than username and password are required, this model does not work very well.

This is where FreeNX’s usermode enters the scene. Basically, what it means, is that authentication to nxserver does no longer happen as the nx user but as the end-user himself. Now, the number of SSH sessions is reduced to one that authenticates the user directly by means of SSH’s built-in authentication capabilities, and where nxserver is run under the end-user credentials instead of the nx user. This, obviously, kills the centralized approach originally envisioned by NoMachine, since now all the control and session files can’t be stored easily and securely in a central location but are now stored in the user’s home directory. But I think the upsides of the usermode support outdo the lack of centralized management. At least in my case, I don’t need centralized management since it’s me who manages all my boxes and logs into them.

How to install and configure FreeNX to support usermode

Next I describe what I had to do, both on the remote machine and also on the client, to get a working FreeNX environment that supports usermode. Other modes are also supported, like legacy nx-based, SUID and others.

Download NX4U tarball from BerliOS and extract it

$ wget http://download.berlios.de/freenx/NX4U.tar.gz
$ sudo tar -C /opt -zxf NX4U.tar.gz

NOTE: The NX4U tarball that I used can also be downloaded from this Web site here.

NOTE: The NX4U set and the nxssh wrapper are smart enough so that you can also extract the NX4U tarball in other locations. Looking at the source code for the nxssh wrapper — nxssh-4US.c — nxssh wrapper uses the following PATH to locate the nxserver binary:

#define NXSERVER_PATH \
"~/bin:
~/NX4U/:
/usr/NX/bin:
/opt/NX/bin:
/opt/NX4U/bin:
/usr/NX4U/bin:
/usr/local/NX4U/bin:
/usr/lib/nx/bin"

Compile the nxssh wrapper

First, download the source code from the SVN repository:

$ svn checkout https://developername@svn.berlios.de/svnroot/repos/freenx/trunk

NOTE: I saved a copy of the SVN repository that I used. The tarball is available in this Web site here.
Build the nxssh wrapper for Mac OS X. nxssh is a simple C program that currently compiles for me with no problems on Linux and Mac OS X:

$ cd trunk/freenx-utils/nxpublickey/
$ make nxssh

NOTE: The Makefile also has a target named nxssh.exe to compile the wrapper for Windows.

Now, let’s rename NoMachine’s nxssh binary to mxssh (the nxssh wrapper expects NoMachine’s nxssh binary to be renamed to mxssh), then install the nxssh wrapper:

$ sudo bash
# mv /usr/NX/bin/nxssh /usr/NX/bin/mxssh
# install -m755 nxssh /usr/NX/bin/nxssh
# ^D

Configure .ssh/config

What looks like a bug in NoMachine’s nxssh, will cause authentication requests using public key to fail with a "percent_expand: NULL replacement" error unless .ssh/config is modified to explicitly state the location of the public key. For example:

Host my.host.org
        IdentityFile ~/.ssh/id_dsa

Configure nxclient

In order to use usermode authentication, make sure to prepend the hostname with the @ (at) sign:

Hostname: @my.host.org

Also, make sure the username has the @ (at) sign prepended plus @U (at U) appended. These non-standard forms are parsed by the nxssh wrapper and enable usermode authentication (or other authentications like SUID):

Username: @myself@U

For more information about possible syntaxes, take a look at freenx-utils/nxpublickey/nxssh-wrapper (the shell script implementation of the nxssh wrapper).

Enabling Kerberos/GSSAPI support in Leopard’s Remote Login (SSH) service is straightforward. As Leopard’s Remote Login is built using OpenSSH, most of what is described here applies perfectly to other flavors of UNIX.

Kerberos/GSSAPI authentication allows for Single Sign-On capabilities in OpenSSH in such a way that it makes very convenient to work with or manage multiple machines while only having to authenticate to the network every certain amount (Kerberos uses a form of cached credentials that expire within hours, typically). In this document I describe how to enable support for Kerberos/GSSAPI authentication to Leopard’s implementation of OpenSSH. Leopard includes many of the tools from the MIT’s implementation of Kerberos, so this makes the whole process even easier.

The process consists on:

1. Creating the Kerberos principal
2. Creating /etc/krb5.conf
3. Adding the Kerberos principal to the keytab file
4. Reconfiguring OpenSSH to support Kerberos authentication
5. Restarting OpenSSH
6. Enabling Kerberos authentication on OpenSSH clients
7. Testing

1. Creating the Kerberos principal

When a Kerberized SSH client tries to authenticate to a Kerberized OpenSSH service, the client will request a Kerberos service ticket for that specific OpenSSH service. The Kerberos service ticket contains, among other things, a shared secret (for example, a 3DES private key) that has to be distributed to both the client and the server, called K<>client,server. The KDC will generate such shared secret and will encrypt it twice. Once, with a shared secret between the KDC and the client principal, called K_KDC,client, and another one with a shared secret between the KDC and the server principal, K_KDC,server.

In this step, we will create the Kerberos principal that represents the OpenSSH server and consequently its shared secret, K_KDC,server. Later on, we will upload this shared secret to the OpenSSH server and install it into the Keytab file, so that the OpenSSH server can access it and use it to decrypt the user’s service ticket in order to retrieve the shared secret, K_{client,server}.

$ kadmin
Authenticating as principal alice/admin@LAN with password.
Password for alice/admin@LAN:
kadmin:  addprinc -randkey host/ssh.lan
WARNING: no policy specified for host/ssh.lan@LAN; defaulting to no policy
Principal "host/ssh.lan@LAN" created.

NOTE: If you are logged in as root into the KDC, you can use kadmin.local instead of kadmin if you prefer, as the former doesn’t require any authentication (being able to run it as root is enough to prove yourself authorized).

The Kerberos principal associated with the OpenSSH has been created, the shared secrets generated, stored and protected by the stash key. We can check the status of the principal using the following command:

kadmin:  getprinc host/ssh.lan
Principal: host/ssh.lan@LAN
Expiration date: [never]
Last password change: Thu Dec 06 19:42:50 CET 2007
Password expiration date: [none]
Maximum ticket life: 0 days 10:00:00
Maximum renewable life: 7 days 00:00:00
Last modified: Thu Dec 06 19:42:50 CET 2007 (root/admin@LAN)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 5, Triple DES cbc mode with HMAC/sha1, no salt
Key: vno 5, DES cbc mode with CRC-32, no salt
Attributes:
Policy: [none]
kadmin:  exit

Now that the principal has been created, we can move onto the next step.

2. Creating /etc/krb5.conf

One of the requirements for Kerberizing OpenSSH server is configuring the Kerberos libraries via /etc/krb5.conf. These libraries are used by the OpenSSH server, kpasswd, the OpenSSH client and tools like kadmin or kinit.

This configuration file will also allow us to connect to the Kerberos administration server remotely by using kadmin, in order to download the OpenSSH shared secret. In my case, /etc/krb5.conf looks like this:

[libdefaults]
        default_realm = LAN
        dns_fallback = "no"
        default_tgs_enctypes = des-cbc-crc
        default_tkt_enctypes = des-cbc-crc

[realms]
        LAN = {
                kdc = kdc.lan:88
                admin_server = kdc.lan:749
        }

[domain_realm]
        .lan = LAN

[login]
        krb4_convert = true
        krb4_get_tickets = false

3. Adding the Kerberos principal to the keytab file

root@ssh.lan:# kadmin
Authenticating as principal root/admin@LAN with password.
Password for root/admin@LAN:
kadmin:  ktadd -k /etc/krb5.keytab host/ssh.lan@LAN
Entry for principal host/ssh.lan@LAN with kvno 7,
 encryption type Triple DES cbc mode with HMAC/sha1 added to
 keytab WRFILE:/etc/krb5.keytab.
Entry for principal host/ssh.lan@LAN with kvno 7,
 encryption type DES cbc mode with CRC-32 added to
 keytab WRFILE:/etc/krb5.keytab.

This will add the OpenSSH shared secret to the Kerberos /etc/krb5.keytab file. We need to add the shared secrets to this file properly, as Leopard has a built-in KDC service and machine-specific shared secrets in this file that are used, among others, by the Screen Sharing service, the AFP service and the SAMBA service.

To check that OpenSSH shared secret was added to the keytab file, we use ktutil to read and display the contents of the Keytab file:

root@ssh.lan:# ktutil
ktutil:  rkt /etc/krb5.keytab
ktutil:  list
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
   1    3 afpserver/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   2    3 afpserver/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   3    3 afpserver/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   4    3 cifs/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   5    3 cifs/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   6    3 cifs/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   7    3 vnc/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   8    3 vnc/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
   9    3 vnc/LKDC:SHA1.E803840ADEAA3E91BF895E969F56FEDFF321BDD5@LKDC...
  10    7                      host/ssh.lan@LAN
  11    7                      host/ssh.lan@LAN

Once installed in the keytab file, OpenSSH will be able to access the shared secret, K_KDC,server used to decrypt Kerberos service tickets shown by clients.

It is also necessary to change OpenSSH’s server configuration file, /etc/sshd_config to explicitly enable Kerberos/GSSAPI authentication. To achieve this, modify /etc/sshd_config file and add the following lines (by default they are either uncommented or disabled):

# GSSAPI options
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

5. Restarting OpenSSH

To last step on the server side requires that we restart the OpenSSH service so the previous changes are taken into effect:

root@ssh.lan:# launchctl
aunchd% stop com.openssh.sshd
launchd% start com.openssh.sshd

6. Enabling Kerberos authentication on OpenSSH clients

Some OpenSSH clients have Kerberos authentication disabled by default. The easiest way to enable Kerberos/GSSAPI authentication in clients is by adding the following directives to $HOME/.ssh/config:

Host *
        Protocol 2
        GSSAPIAuthentication yes
        GSSAPIKeyExchange yes
        GSSAPIDelegateCredentials no
        GSSAPITrustDns no

This will enable Kerberos/GSSAPI authentication on the client side. The fact that Kerberos/GSSAPI authentication succeeds depends on several factors, like the user having a valid Kerberos TGT, the remote server having Kerberos/GSSAPI authentication enabled, and that the clocks on both the client and server machines are synced (most implementations refuse Kerberos/GSSAPI authentication if the clocks differ more than 5 minutes).

7. Testing

First, we need to get a TGT from the Kerberos KDC:

$ kinit
Please enter the password for falfaro@LAN:

To check that it worked, we list the tickets available to us, and make sure we see a ticket valid for service krbtgt/*:

$ klist
Kerberos 5 ticket cache: 'API:Initial default ccache'
Default principal: falfaro@LAN

Valid Starting     Expires            Service Principal
12/06/07 18:06:26  12/07/07 04:06:26  krbtgt/LAN@LAN
	renew until 12/13/07 18:06:26

Now, let’s try to log in into the OpenSSH server. Kerberos/GSSAPI authentication should be negotiated, as shown by the debugging information:

core2:~ falfaro$ ssh -v solana
OpenSSH_4.5p1, OpenSSL 0.9.7l 28 Sep 2006
debug1: Reading configuration data /Users/falfaro/.ssh/config
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to solana [10.42.242.12] port 22.
debug1: Connection established.
debug1: identity file /Users/falfaro/.ssh/id_rsa type -1
debug1: identity file /Users/falfaro/.ssh/id_dsa type 2
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.5
debug1: match: OpenSSH_4.5 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_4.5
debug1: Offering GSSAPI proposal:
 gss-gex-sha1-toWM5Slw5Ew8Mqkay+al2g==,
 gss-group1-sha1-toWM5Slw5Ew8Mqkay+al2g==,
 gss-group14-sha1-toWM5Slw5Ew8Mqkay+al2g==,
 gss-gex-sha1-A/vxljAEU54gt9a48EiANQ==,
 gss-group1-sha1-A/vxljAEU54gt9a48EiANQ==,
 gss-group14-sha1-A/vxljAEU54gt9a48EiANQ==,
 gss-gex-sha1-bontcUwnM6aGfWCP21alxQ==,
 gss-group1-sha1-bontcUwnM6aGfWCP21alxQ==,
 gss-group14-sha1-bontcUwnM6aGfWCP21alxQ==
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-cbc hmac-md5 none
debug1: kex: client->server aes128-cbc hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'solana' is known and matches the RSA host key.
debug1: Found key in /Users/falfaro/.ssh/known_hosts:8
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue:
 publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Authentication succeeded (gssapi-with-mic).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
Last login: Thu Dec  6 20:29:59 2007 from foo.lan
$ hostname
ssh.lan
$ exit
logout
Connection to solana closed.

If we run klist again, we will see that, in addition to the TGT we saw before, we will see the Kerberos service ticket for the OpenSSH server:

Kerberos 5 ticket cache: 'API:Initial default ccache'
Default principal: alice@LAN

Valid Starting     Expires            Service Principal
12/06/07 18:06:26  12/07/07 04:06:26  krbtgt/LAN@LAN
	renew until 12/13/07 18:06:26
12/06/07 18:07:27  12/07/07 04:06:26  host/ssh.lan@LAN
	renew until 12/13/07 18:06:26

8. Troubleshooting

The GSSAPI authentication mechanism is very picky about many things, and error codes and messages are usually very cryptic but not very helpful about what the cause of the error is.

I found that acommon source of authentication problems are entries in /etc/hosts confusing GSSAPi about the host name. For example, entries like this in /etc/hosts:

192.168.0.1  ssh ssh.lan

can cause SSH to think the host name is ssh instead of the expected FQDN — ssh.lan.The previous entry causes reverse name resolutions for IP 192.168.0.1 to return ssh as the host name, but not ssh.lan. Since the Kerberos keytab is host/ssh.lan but IP 192.168.0.1 is resolved to ssh this may cause authentication attempts to fail because no Kerberos keytab for host/ssh exists in /etc/krb5.keytab. The most common symptom is trying to SSH to localhost, getting a failed authentication and but ticket for the target host. Example:

$ kinit
Password for alice@LAN: 

$ klist
Ticket cache: FILE:/tmp/krb5cc_501
Default principal: alice@LAN

Valid starting     Expires            Service principal
05/31/09 01:08:21  06/01/09 01:08:20  krbtgt/LAN@LAN

Then,

$ ssh ssh.lan
alice@ssh.lan's password:

But no Kerberos ticket for ssh.lan was even requested:

$ klist
Ticket cache: FILE:/tmp/krb5cc_501
Default principal: alice@LAN

Valid starting     Expires            Service principal
05/31/09 01:08:21  06/01/09 01:08:20  krbtgt/LAN@LAN

One possible solution consists of removing the matching entry from /etc/hosts, provided that the existing DNS name server can properly resolve the IP address of the server to the correct FQDN. If this is not possible, another solution is making sure the FQDN name is listed before the non-FQDN name in the corresponding line in /etc/hosts.

8. References

Some additional and very useful references:

• Kerberos 5 setup for NFSv4.

  Describes common pitfalls, like using a non-FQDN host name in /etc/hosts or not using clock synchronization.

The configuration of the automounter starts with the master configuration file, /etc/auto_master The contents of this file look like this:

#
# Automounter master map
#
+auto_master		# Use directory service
/net			-hosts		-nobrowse,nosuid
/home			auto_home	-nobrowse
/Network/Servers	-fstab
/-			-static

Here is a brief description of each one:

• /net -hosts -nobrowse,nosuid

  This configures automount of NFS servers in /net. Automounting is done for any resolvable host name (it doesn’t have to have an entry in /etc/hosts and it’s browsable under /net. The problem is that /net is not linked from the sidebar in Finder, and thus not very useable except from the command-line.

• /home auto_home -nobrowse

  This configures automounting of home directories via a directory service, as configured in /etc/auto_home.

• /Network/Servers -fstab

  This line states that all mount entries defined in /etc/fstab should be mounted in /Network/Servers. However, this is not entirely true as mount entries listed in /etc/fstab have to specify an absolute mount point, or else automount will complain. Since mount entries specify an absolute mount point, and it won’t be overridden by automount, in order to make Finder show the entries in the sidebar it is recommended that the mount point is located in a subdirectory within /Networ/.

  For example, this how my /etc/fstab file looks like:

  media:/export /Network/media nfs nosuid,nodev 0 0
  

• /- -static

  This entry is very similar to the previous one, but instead of using /etc/fstab as the source of mount entries, this one uses the local directory service instead. Entries can be configured using Directory Utility, and stored as a plist file in /var/db/dslocal/nodes/Default/mounts.

  Here is an example of a file named /var/db/dslocal/nodes/Default/mounts/media.lan\:%2Fexport.plist:

  <?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
  <plist version="1.0">
  <dict>
  	<key>dir</key>
  	<array>
  		<string>/Network/media</string>
  	</array>
  	<key>generateduid</key>
  	<array>
  		<string>1895C8D3-7DBF-4857-8D61-04080DFA5B55</string>
  	</array>
  	<key>name</key>
  	<array>
  		<string>media.lan:/export</string>
  	</array>
  	<key>opts</key>
  	<array>
  		<string>nosuid</string>
  		<string>nodev</string>
  	</array>
  	<key>vfstype</key>
  	<array>
  		<string>nfs</string>
  	</array>
  </dict>
  </plist>
  

Reloading the automount configuration is just as simple as running:

automount -vc

automount will reload its configuration and will automatically mount any entry listed in /etc/fstab. Additionally, the Finder will display an All… link in the sidebar that makes very easy to get to the automounted volumes.

• Allow all incoming connections.

  Seems obvious that choosing this setting means that the firewall is essentially disabled and any traffic can freely flow in and out of the computer.

  I would not recommend this setting, even for trusted networks. It is easy for a laptop computer to attach to a different network at any time and have the user forget to re-enable the firewall, posing as a potential victim for other users or computers. For a desktop computer it is more and more common to be attached to a network that has some sort of wireless bridging or routing device that might be used by untrusted users to get access to the network, or by trusted users that carry (maybe without their knowledge) malware, for example.

  This setting offers little or no security, but makes very easy to share contents or provide external services.

• Block al incoming connections.

  This seems the safest choice, but might not always be desirable if you are sharing content or have services running that you want to make accessible from the outside (like an SSH server, or even the iTunes music collection).

  This is my preferred setting, I have to say. This setting offers adequate security, but stops you from sharing content or offering access to services externally. However, it seems that Leopard’s firewall does not block all services, and some of them are still accessible from the outside (see at the end of the post for more information).

• Set access for specific services and applications.

  This is by far the most confusing setting. First, because it doesn’t seem to add any rules to IPFW. I’m starting to believe that Leopard offers two layers of filtering. It seems IPFW is one of them, but it defaults to use a ruleset with only default accept entry in it (sequence 65535):

  # ipfw list
  65535 allow ip from any to any
  

  (NOTE: if you enable the Stealth functionality, a IPFW rule is added before the default entry, and it looks like this:

  33300 deny icmp from any to me in icmptypes 8
  

  This blocks ICMP Echo Requests, but be aware that Stealth mode is not enabled by default).

  About the other filtering layer, I’m not sure what it is used or how it is implemented, but it seems to be the result of some sort of kernel-level and user-space cooperation. The second reason why I think this setting can be confusing is because it seems to only affect a particular user (normally the logged user), but not the system or other users like root.

  For example, I compiled synergy and ran it as user root. Then, I configured the Leopard’s firewall for access to specific services and applications, but I left the list empty. I verified that I could reach the synergys server at port 24800 from other computer in the same network segment. I was really surprised, to be honest.

  The next thing I tried is to kill synergys and to re-run it as my currently logged in user. This time, Leopard presented me with a dialog box that asked whether to allow synergys to accept incoming connections:

  Do you want the application “synergys” to accept incoming network connections?

  Clicking Deny may limit the application’s behavior. This setting can be changed in the Firewall pane of Security Preferences.

  This caused the expected behavior: any attempt to connect to port 24800 from the outside was blocked by Leopard’s firewall:

  22:02:30.989097 IP 10.42.242.16.49950 > 10.42.242.12.24800:
    S 3207271609:3207271609(0) win 65535
    <mss 1460,nop,wscale 3,nop,nop,timestamp 699234003 0,sackOK,eol>
  22:02:31.913244 IP 10.42.242.16.49950 > 10.42.242.12.24800:
    S 3207271609:3207271609(0) win 65535
    <mss 1460,nop,wscale 3,nop,nop,timestamp 699234012 0,sackOK,eol>
  22:02:32.914300 IP 10.42.242.16.49950 > 10.42.242.12.24800:
    S 3207271609:3207271609(0) win 65535
    <mss 1460,nop,wscale 3,nop,nop,timestamp 699234022 0,sackOK,eol>
  22:02:33.915334 IP 10.42.242.16.49950 > 10.42.242.12.24800:
    S 3207271609:3207271609(0) win 65535
    <mss 1460,sackOK,eol>
  22:02:34.916398 IP 10.42.242.16.49950 > 10.42.242.12.24800:
    S 3207271609:3207271609(0) win 65535
    <mss 1460,sackOK,eol>
  22:02:35.917319 IP 10.42.242.16.49950 > 10.42.242.12.24800:
    S 3207271609:3207271609(0) win 65535
    <mss 1460,sackOK,eol>
  22:02:37.919629 IP 10.42.242.16.49950 > 10.42.242.12.24800:
    S 3207271609:3207271609(0) win 65535
    <mss 1460,sackOK,eol>
  22:02:41.924491 IP 10.42.242.16.49950 > 10.42.242.12.24800:
    S 3207271609:3207271609(0) win 65535
    <mss 1460,sackOK,eol>
  

  Note how the first three segments had the time-stamp and window scaling options activated. The remaining SYN segments didn’t. This is probably due to Leopard thinking that there was congestion or that it was talking to an old system.

  Once I chose Always allow, Leopard added an entry into the Firewall list named synergys. From here on, I was able connect to port 24800. This is the the network capture that tcpdump displayed when trying to connect to port 24800 from another compuer after synergys had been granted access:

  22:24:20.674656 IP 10.42.242.16.50055 > 10.42.242.12.24800:
    S 2514913060:2514913060(0) win 65535
    <mss 1460,nop,wscale 3,nop,nop,timestamp 699247086 0,sackOK,eol>
  22:24:20.675544 IP 10.42.242.12.24800 > 10.42.242.16.50055:
    S 812848149:812848149(0) ack 2514913061 win 65535
    <mss 1460,nop,wscale 1,nop,nop,timestamp 473026159 699247086,sackOK,eol>
  22:24:20.675591 IP 10.42.242.16.50055 > 10.42.242.12.24800:
    . ack 1 win 65535 <nop ,nop,timestamp 699247086 473026159>
  22:24:20.677911 IP 10.42.242.12.24800 > 10.42.242.16.50055:
    P 1:16(15) ack 1 win 33304 <nop ,nop,timestamp 473026159 699247086>
  22:24:20.677959 IP 10.42.242.16.50055 > 10.42.242.12.24800:
    . ack 16 win 65535 <nop ,nop,timestamp 699247086 473026159>
  

  Funny enough, keeping my telnet client running while trying to connect at port 24800, waiting for Leopard to remove the time-stamp and window scaling options, then allowing this traffic, didn’t make Leopard to try to re-negotiate the time-stamp and window scaling options.

  Another thing worth mentioning is that once synergys had been granted access to incoming traffic at port 24800, removing it from the list of allowed applications and services didn’t stop it from receiving traffic. To block synergys from receiving traffic it was necessary to change Allow incoming connections to Block incoming connections (removing its entry from the list did still allow it to receive incoming traffic).

  Another interesting feature is that Leopard’s seems to be aware of service dependency. For example, enabling the Screen Sharing service also starts a local Kerberos 5 KDC which is used to authenticate users. This is fascinating since users of Screen Sharing, for example, will first request a TGT to this local Kerberos 5 KDC (and will be able to decrypt that TGT if they know the correct password), then using the TGT request a service ticket for the Screen Sharing service that can present to it in order to get authenticated. But moreover, trying to connect to the Screen Sharing service for a second time will not require the user to provide his credentials again because a Kerberos service ticket is already available (provided that it didn’t expire). This is Single Sign-On in its true form.

Conclusion

In conclusion, I can’t say that the graphical user interface provides a lot of room for configuration, neither does it offer any way to configure egress filtering (that is, traffic that originates on the local computer and is to be sent out externally via a network interface).

In general, Leopard’s default administration tools are probably on par with those from Windows Vista. Even though the underpinnings of the newest member of the Mac OS X family are powered by IPFW, I feel Leopard’s firewall has a long way to go to in order to get closer to the powerful functionality and configurability of PF or Netfilter/IPtables, for example.

Also, not enabling the firewall by default is a big mistake in my opinion. One of my Mac OS X laptops is listening on port 111/tcp, 1020/tcp and 1021/tcp. The first one is iCalAlarmAgent and the other two are related to launchd. Even if you configure the firewall to block all traffic, these three ports are still accessible from the outside.