Felipe Alfaro Solana

Introduction

DISCLAIMER: The contents of this post are mostly based on Manual Installation How-To. Thanks to Brent Davidson and Fabian Franz for writing such a nice HowTo and the beautiful open and free implementation of FreeNX, respectively.

I decided to use FreeNX instead of NoMachine’s own implementation due to the instability of the latter. Most of the times, I could not reconnect to my running sessions, or else NX decided to kill my running session and start a new one. FreeNX is a collection of shell scripts, which makes it easier to debug and troubleshoot problems.

The process described in this post starts with the NoMachine’s binary components, downloadable from the Web, and then overwrites or replaces key components that are binary-only and closed with FreeNX’s open and free shell scripts, which provides much more flexibility. In my own experience, FreeNX is more robust, stable, predictable, easier to customize and to debug than NoMachine’s closed binary components.

Installing the base NoMachine’s NX binary components

Download nxclient, nxnode and nxserver from NoMachine as .tar.gz files. The files can be found in the NoMachine downloads or can be downloaded directly from this site, if you trust me:

For IA-32 systems:

• nxclient-3.0.0-84.i386.tar.gz
• nxnode-3.0.0-93.i386.tar.gz
• nxserver-3.0.0-79.i386.tar.gz

For x86_64 systems:

• nxclient-3.0.0-84.x86_64.tar.gz
• nxnode-3.0.0-93.x86_64.tar.gz
• nxserver-3.0.0-79.x86_64.tar.gz

Extract the files to /usr. Since the .tar.gz packages always contain relative pathnames that start with ./NX, this will create a whole directory tree under /usr/NX.

# tar -C /usr –xzf nxserver-3.0.0-79.i386.tar.gz
# tar -C /usr –xzf nxclient-3.0.0-84.i386.tar.gz
# tar -C /usr –xzf nxnode-3.0.0-93.i386.tar.gz

Compiling the NX compression libraries

Compiling nxcomp

Download the source code for nxcomp from NoMachine’s source code or here from
nxcomp-3.0.0-48.tar.gz.

The ./configure is not very robust and doesn’t check for missing dependencies. This are the packages that are needed to compile nxcomp:

# apt-get install zlib1g-dev libX11-dev libjpeg-dev libpng12-dev \
    x11proto-xext-dev libxdamage-dev libxrandr-dev libxtst-dev \
    libaudiofile-dev

Configuring, building the library and copying it to its final location is just as easy as running:

# tar -xzf nxcomp-3.0.0-48.tar.gz
# cd nxcomp
# ./configure --prefix=/usr/NX
# make
# cp -P libXcomp.so* /usr/NX/lib

Compiling nxcompext

Download the source code for nxcompext and nx-X11 from NoMachine’s source code or here from
nxcompext-3.0.0-18.tar.gz and nx-X11-3.0.0-37.tar.gz, and extract them:

# tar -xzf nxcompext-3.0.0-18.tar.gz
# tar -xzf nx-X11-3.0.0-37.tar.gz

Before compiling nxcompext, apply the NXlib-xgetioerror.patch.

# cd nxcompext
# patch -p0 < NXlib-xgetioerror.patch

This is required or else the resulting libXcomp.so shared library will complain about _XGetIOError symbol being undefined. In order to troubleshoot this, I had to enable logging in /usr/NX/etc/node.conf:

NX_LOG_LEVEL=7
SESSION_LOG_CLEAN=0
NX_LOG_SECURE=0

Then, looking at /var/log/nxserver.log I found the following error message:

Info: Established X client connection.
Info: Using shared memory parameters 1/1/1/4096K.
Info: Using alpha channel in render extension.
Info: Not using local device configuration changes.
/usr/NX/bin/nxagent: symbol lookup error: /usr/NX/lib/libXcompext.so.3:
undefined symbol: _XGetIOError
NX> 1006 Session status: closed

Applying the patch solves the problem:

# ./configure --x-includes="/usr/include/xorg -I/usr/include/X11" --prefix=/usr/NX
# make
# cp -P libXcompext.so* /usr/NX/lib

Compiling nxcompshad

Download the source code for nxcompshad from NoMachine’s source code or here from
nxcompshad-3.0.0-19.tar.gz.

# tar -xzf nxcompshad-3.0.0-19.tar.gz
# cd nxcompshad
# ./configure --prefix=/usr/NX
# make
# cp -P libXcompshad.so* /usr/NX/lib

Compiling nxesd

Download the source code for nxesd from NoMachine’s source code or here from
nxesd-3.0.0-4.tar.gz.

# tar -xzf nxesd-3.0.0-4.tar.gz
# cd nxesd
# ./configure --prefix=/usr/NX
# make
# make install

Installing FreeNX

Download FreeNX from FreeNX downloads, or from this Web site at freenx-0.7.1.tar.gz and extract them and apply the gentoo-machine.diff patch:

# tar -xzf freenx-X.Y.Z.tar.gz
# cd freenx-X.Y.Z
# patch -p0 < gentoo-nomachine.diff

The gentoo-machine.diff patch must be applied if you are using the /usr/NX directory structure that the NoMachine libraries use.

Next, we replace the original NoMachine key binaries (in fact, they are compiled Perl scripts) with the FreeNX shell scripts:

# cp -f nxkeygen /usr/NX/bin/
# cp -f nxloadconfig /usr/NX/bin/
# cp -f nxnode /usr/NX/bin/
# cp -f nxnode-login /usr/NX/bin/
# cp -f nxserver /usr/NX/bin/
# cp -f nxsetup /usr/NX/bin/
# cp -f nxcups-gethost /usr/NX/bin/

Next, we need to compile the nxserver-helper binary, which is used by the slave mode of nxnode. Basically, nxserver-helper runs a command that has both /dev/fd/3 and /dev/fd/4 mapped into both ends of a UNIX SOCKET.

# cd nxserver-helper
# make
# cp -f nxserver-helper /usr/NX/bin/

Before being able to set up the FreeNX, install expect, the OpenSSH server and smbmount and smbumount:

$ sudo apt-get install expect smbfs openssh-server

The next step creates symbolic links in /usr/bin to all FreeNX scripts that live in /usr/NX/bin and additional symbolic links for NX compatibility:

# ln -s /usr/NX/bin/nxserver /usr/bin/nxserver
# ln -s /usr/NX/bin/nxsetup /usr/sbin/nxsetup
# ln -s /usr/NX/bin/nxloadconfig /usr/sbin/nxloadconfig
# ln -s /usr/NX/lib/libXrender.so.1.2.2 /usr/NX/lib/libXrender.so.1.2
# ln -s /usr/NX/bin/nxagent /usr/NX/bin/nxdesktop
# ln -s /usr/NX/bin/nxagent /usr/NX/bin/nxviewer
# ln -s /usr/bin/foomatic-ppdfile /usr/lib/cups/driver/foomatic-ppdfile
# ln -s /etc/X11/xinit /etc/X11/xdm
# ln -s /sbin/mount.cifs /sbin/smbmount
# ln -s /sbin/umount.cifs /sbin/smbumount

The final step consists is running the installation stage of FreeNX:

# nxsetup --install

This will create /usr/NX/var directory tree, create the nx user, install the appropiate SSH keys (either the NoMachine’s keys or custom keys).

Before being able to use FreeNX, create the node.conf configuration file that allow changing the behavior of FreeNX, like logging, path names to several scripts used to start GNOME or KDE, and so on:

# cd freenx-X.Y.Z
# cp node.conf.sample /usr/NX/etc/node.conf

Future development and ideas

• Not having to depend on any single binary file from NoMachine.

  The idea is compiling all the components from source code, instead of starting with a binary distribution and replacing key components with their open and free counterparts.

• Customizing FreeNX so that I can bypass NoMachine’s nxclient completely.

  Most of my network components are Kerberized and having to keep supplying my password to nxclient seems like a thing of the past to me. The idea is customizing FreeNX in such a way that I can leverage Kerberos authentication and drop password-based authentication completely.

The AutoFS service in Leopard, also known as automount, is configured by means of text files stored in /etc and the automount command-line utility. The standard automount configuration also allows for local directory service lookups and thus can also be configured by using Directory Utility.

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.

Yesterday I was trying to translate some text in German to English, like this one:

Für sämtliche Fragen rund um den Zürcher Verkehrsverbund steht Ihnen ZVV-Contact oder Ihre Verkaufsstelle gerne zur Verfügung.

And the text was translated to this:

For all questions about the ZVV you ZVV-Contact or sell your body to be happy.

I don’t know if I should sell my body, and also I’m not sure about the price. But what I’m sure about is that the translation should have looked like this instead:

For any questions about the Zürich Public Transportation Authority you can contact ZVV or the closest sales agency.

If you don’t believe me, you can click the next image:

Introducción

En los sistemas convencionales, el votante se dirige a un colegio electoral, introduce su voto, en forma de papeleta, en un sobre, se identifica ante un agente e introduce su voto en una urna. Los sistemas tradicionales separan el proceso de autentificación del votante del proceso recuento de votos, de forma que éstos se realizan de forma independiente.

El proceso de autentificación no tiene acceso al contenido del voto y sirve meramente para evitar que sólo los individuos autorizados puedan ejercer su derecho al voto. Así mismo, el proceso de autentificación es capaz de evitar votos duplicados, es decir, la emisión del mismo voto más de una vez por el mismo individuo, y también es capaz de ofrecer el cómputo de votos recibidos y calcular estadísiticas como el porcentaje de votos recibidos sobre el total de la población con derecho a voto.

El modelo tradicional confía en que el proceso de autentificación fue correctamente realizado, que el transporte entre el sistema de autentificación y el sistema de recuento es fiable (no hay pérdida de datos, ni manipulación del canal, como la eliminación de votos, etc.) y que el registro de los votos no fue alterado. El proceso de recuento es capaz de clasificar el conjunto total de los votos según su contenido, normalmente en un número discreto, finito y normalmente reducido de posibilidades.

Se desea una implementación de sistema de voto electrónico que permita la autentificación del votante a la vez que mantenga el anonimato del voto, conservando la semántica de los sistemas de voto tradicionales.

Presentación

Se propone una solución de voto electrónico en la que intervienen tres entidades:

• El votante
• Un sistema de autentificación
• Un sistema de recuento o registro de votos

El voto se introduce en un sobre, cuyo destinatario final es el sistema de recuento. Este sobre, a su vez, se introduce en otro cuyo destinatario final es el sistema de autentificación. El voto, encapsulado en dos sobres, pasará por los dos sistemas. Primero por el sistema de autentificación que comprobará la identidad del votante, así como que el votante no haya votado ya alguna vez. El sistema de autentificación no tendrá acceso al segundo sobre, que contiene el voto en sí mismo. De esta forma, el voto se oculta del sistema de autentificación. Una vez autentificada la identidad del votante, y sin conocer el contenido del voto, el segundo sobre se envía al sistema de recuento que registrará el voto. El sistema de autentificación elimina la firma digital del votante y la sustituye por la suya a fin de permitir el voto anónimo.

El objetivo del entorno es que el sistema de autentificación no tenga acceso al voto en sí mismo (anonimato) pero pueda validar la identidad del votante, y que el sistema de recuento tenga acceso al voto en sí mismo pero no a la identidad del votante.

Para ello, se propone el siguiente sistema basado en criptografía de clave pública:

Premisas

El votante sólo conoce K_EV, K_DV (su pareja de claves pública y privada) así como K_EA y K_ER. El sistema de autentificación sólo conoce K_EV, así como K_EA, K_DA (su pareja de claves pública y privada) y K_ER. El sistema de recuento sólo conoce K_EA, así como K_ER y K_DR (su pareja de claves pública y privada).

Implementación

A la hora de emitir su voto electrónico, el votante emite el siguiente mensaje, destinado al sistema de autentificación:

Una vez en posesión de M_V, el sistema de autentificación puede validar la firma digital de M_V descrifándolo con la clave pública del votante, K_EV, y obteniendo:

El sistema de autentificación puede validar la autenticidad del votante, pero sin tener acceso al contenido del voto en sí mismo, V, al no tener el sistema de autentificación acceso a K_DR. El sistema de autentificación debe establecer que ID_V coincide con la identidad del votante (por ejemplo, su NIF). En ese caso, el sistema de autentificación validará que el votante V no haya votado con anterioridad, comprobando que la estampa de tiempo TS₁ no difiera de la estampa horaria actual en más de un periodo determinado como seguro (por ejemplo, 48 horas). Si la identidad del votante no puede ser comprobada o la estampa horaria TS₁ está fuera del intervalo permitido, el mensaje se descarta. En caso contrario, el sistema de autentificación emite el siguiente mensaje, M_A, destinado al sistema de recuento:

El sistema de recuento deberá verificar la firma digital de M_A. De ser correcta, el sistema de recuento tendrá acceso a:

De no ser correcta, el mensaje M_V será descartado. El sistema de recuento comprobará que TS₁ = TS₂ ±εy que tanto TS₁ como TS₂ estén dentro de unos márgenes de tiempo aceptables. En ese caso, se podrá proceder a obtener el voto V y registrarlo en un sistema de almacenamiento que sea tamper-resistant (resistente a modificaciones maliciosas o no autorizadas).

Al diferencia de los sistemas tradicionales, donde los votos se acumulan en su totalidad en el sistema de autentificación hasta el cierre de la recepción de votos, el modelo descrito permite dos posibilidades:

• Acumulación previa:

  Una vez se finalice la admisión de votos, el sistema puede enviar el conjunto de todos los M_A acumulados, más el cardinal de dicho conjunto, como un mensaje único firmado digitalmente por el sistema de autentificación.

  Esto ofrece una reducción en la posibilidad de que un agente externo pueda manipular el canal de comunicación entre el sistema de autentificación y el de recuento, invalidando la votación. A su vez, hace que un agente externo pueda invalidar la votación con tan sólo manipular el estado del sistema de autentifcación. Se disminuye el riesgo de compromiso del canal, pero se aumenta el riesgo en caso de compromiso del sistema de autentificación.

• Envío inmediato:

  Esto ofrece una reducción en la posibilidad de que un agente externo pueda manipular el estado del sistema de autentificación (al ser un sistema store-and-forward, el estado se reduce al mínimo), invalidando la votación. A su vez, hace que un agente externo pueda invalidar la votación con tan sólo manipular el canal de comunicaciones mediante la eliminación selectiva de mensajes. Se disminuye el riesgo de compromiso del estado del sistema de autentificación, pero se aumenta el riesgo en caso de compromiso del canal de comunicaciones.

Particularmente, creo que la segunda opción es la más aconsejable: es más sencillo delegar la seguridad del canal de comunicaciones a protocolos como IPSec y la correcta secuenciación de mensajes a TCP que implementar la seguridad en el propio protocolo de voto electrónico.

Autentificación del votante y anonimato del voto

La seguridad del sistema estriba en que el sistema de recuento desconoce la identidad del usuario que emitió el voto V (ID_V), y a la vez que se asegura la autenticidad de éste al ser cada voto anónimo autentificado por el sistema de autentificación. A su vez, el sistema de autentificación sólo tiene acceso a la identidad del usuario que emitió el voto V (ID_V), pero no al contenido de su voto.
La seguridad del sistema depende en la relación de confianza del sistema de recuento sobre el sistema de autentificación, así como la capacidad del sistema de autentificación para validar la identidad ID_V del votante correctamente, y la capacidad del sistema de recuento para almacenar el recuento de votos de manera que no se pueda manipular maliciosamente.

El modelo descrito sólo es capaz de detectar si el contenido de un voto es inválido en el sistema de recuento. Llegado a este punto, y dado que este sistema no tiene acceso a la identidad del votante, lo único que puede hacer es marcar el voto como inválido. El modelo descrito permite, por lo tanto:

• Voto válido
• Voto en blanco
• Voto inválido

Será necesario determinar si estas características son deseables a la hora de aplicar el modelo aquí descrito.

The firewall in Mac OS X 10.5 Leopard is confusing, to say the least. It is not enabled by default, which is a huge mistake, in my humble opinion. Also, the graphical user interface offers less flexibility than in previous version while trying to configure it. Besides allowing you to independently control the blocking of incoming ICMP Echo Requests and logging via syslog, it has the following main operation modes:

• 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.

After experimenting with local files for Mac OS X 10.5 Leopard Directory Service, I read a hint on MacOSXHints name Manage users and groups using a GUI tool.

What this tip describes, basically, is that you can use Mac OS X Server Administration Tools to connect locally to the Directory Service running on Mac OS X Leopard. Just start Workgroup Manager, and authenticate to host localhost with the credentials of any user with administrative rights. Using Workgroup Manager it is possible to create and manage users and groups, but more important is that changes take effect immediately, without having to kill /usr/sbin/DirectoryService, rebooting or having to log out. Very nice!

New with Mac OS X 10.5 is the replacement of the old NetInfo architecture. The new component, Directory Services, is a highly configurable service that can use many back-ends to store, retrieve and abstract concepts like users, groups, machines or mount points.

Directory Services sports LDAP, Active Directory and Open Directory support, and also local files. Local files seem to be stored directly in the root volume, in the /var/db/dslocal/nodes/Default/ directory. Within this subdirectory, we can found others that create a tree-like, hierarchical structure:

• aliases/. Contains a one pList for every account alias that is registered in the Local directory service. There are some built-in aliases, plus additional aliases that can be created from the Accounts preference pane.
• config/. Contains several configuration files for components like Kerberos KDC (in a pretty funny format, that basically looks like XML-syntax wrapper that contains the traditional kdc.conf text-based configuration file as a string), Share points and so on.
• groups/. Contains one pList file for every known local group. The format is pretty straightforward and almost resembles the traditional UNIX /etc/group file, but expressed using XML.
• machines/. Contains one pList file for every known machine. It seems to me this is the equivalent of the /etc/hosts UNIX file where each machine entry is stored in as a single pList file. For a default Mac OS X installation, you will find a localhost.plist and a broadcasthost.plist entry.
• mounts/. Contains one pList for every automount point. By default, there are no automount points defined, and they can be created using the Directory Utility application, dscl or by manually creating or changing pList files.
• networks/. Contains one pList file for every known network. This seems like the equivalent of /etc/ethers in UNIX systems. By default, only a single pList file exists: loopback.plist, which lists 127.0.0.0/8 as a known network.
• users/. Contains one pList file for every known local user. This is the equivalent of /etc/passwd in any UNIX system. As in modern UNIX systems, the password is stored somewhere else (does anybody know where?).

By tweaking these files and restarting the Directory Service, it is possible to emulate the behavior of a UNIX-like system, with the difference that access to these entities is mediated by a service, as is not exposed via a POSIX API that, when configured to use local files, parses the contents of local files. In Mac OS X, it is necessary to notify the Directory Service when the contents of any of the pList files changes.

Another way of editing some of these components without having to use dscl or editing pList files by hand is by right-clicking a user or a group in the Accounts preference pane, then choosing Advanced Options ... from the menu.