Folks,

It's been just over a week since I spoke at WWDC and I'm pretty much still floating! It was pretty nerve wracking, and I was a nervous wreck starting the previous Sunday, when I realized that my OD session was the only IT track session in that time slot on Friday.

QuickLook

This strikes me as a potentially huge security issue. Many of the Outlook e-mail worms spread because of buffer overflows in the IE engine that was used to render the content. These buffer overflows allowed the worm to execute arbitrary code in the user context, not the system context. As a result, the mere act of viewing a message would trigger the worm to attempt to propagate itself to everyone in the user's address book and also act to trigger an attempt to escalate privileges to take over the machine. Granted, a lot of this was made easier by the fact that most Windows users were (at the time) running with Administrator privileges — but that isn't all too different from the way that many Mac users run right now.

QuickLook presents the same kind of vulnerability — multiplied by 100 or 1000! Application vendors will be asked to create rendering engines for their file formats, and if the rendering engine does not handle incorrect input properly, an attacker may cause arbitrary code to execute in the user context, just by having the user click on the file in the Finder. This needs to be sandboxed very carefully or it becomes a huge security vulnerability. Some techniques to harden the system would be a stack canary, address-space layout randomization, and systrace-style constrained file access. I can't comment on which of these (if any) are included in Leopard due to the NDA's, but even with these it is a serious concern. I'd really want a virtual machine-style constraint on what the QuickLook plugin is allowed to do.

OD/Solaris Integration How-To

Just to give you the quick run-down on this, in case you want to try it yourself.

First, steps 1-4 should be executed on Solaris, as root.

1. Make a copy of the /etc/nsswitch.ldap file to /etc/nsswitch.ldap.dist, in case you want to preserve Sun's original configuration.
2. Copy the /etc/nsswitch.conf file to /etc/nsswitch.ldap. Edit the new /etc/nsswitch.ldap file so that the following lines are changed from the original:

passwd: files ldap

group: files ldap

3. Execute the following command, with appropriate adjustments for the search base and Open Directory master IP address:

ldapclient -v manual -a credentialLevel=anonymous -a defaultSearchBase=dc=od-master,dc=example,dc=com -a serviceSearchDescriptor=passwd:cn=users,dc=od-master,dc=example,dc=com -a attributeMap=passwd:gecos=cn -a serviceSearchDescriptor=group:cn=groups,dc=od-master,dc=example,dc=com -a serviceAuthenticationMethod=pam_ldap:simple 10.17.1.1

The elements break down as follows:

-v Verbose output

manual Manual configuration (as opposed to using a config file or creating a config file)

-a credentialLevel=anonymous Use an anonymous bind for basic communication

-a defaultSearchBase=dc=od-master,dc=example,dc=com Default search base

-a serviceSearchDescriptor=passwd:cn=users,dc=od-master,dc=example,dc=com Where to look for user info

-a attributeMap=passwd:gecos=cn Map the gecos attribute in a standard passwd file to the cn attribute for users (long name on Mac OS X)

-a serviceSearchDescriptor=group:cn=groups,dc=od-master,dc=example,dc=com Where to look for group info

-a serviceAuthenticationMethod=pam_ldap:simple Use simple, cleartext LDAP binding for authentication

10.17.1.1 IP address of the Open Directory Master

4. Edit the /etc/pam.conf file so that the block for "other auth" is changed from:

other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth required pam_unix_cred.so.1
other auth required pam_unix_auth.so.1

to

other auth requisite pam_authtok_get.so.1
other auth required pam_dhkeys.so.1
other auth required pam_unix_cred.so.1
other auth binding pam_unix_auth.so.1 server_policy
other auth required pam_ldap.so.1

Your Open Directory users can authenticate to Solaris via ssh, telnet, or what have you.

Now to do Kerberos integration. It's pretty easy.

5. Copy the /Library/Preferences/edu.mit.Kerberos file from the Open Directory Master to /etc/krb5/krb5.conf on Solaris.
6. Open Workgroup Manager, and create a computer record for the fully qualified host name of the Solaris machine; e.g. "solaris10.example.com".
7. Open Server Admin on the Open Directory Master, go to the Open Directory settings, and click on the button "Add Kerberos Record..." Fill in the necessary usernames and password, and the fully qualified host name of the Solaris system, then click on "Add".
8. From the command line on the Open Directory Master, execute

sudo kadmin.local

Once you have the kadmin.local prompt, export the necessary principals to a keytab file by using the following command, substituting the appropriate fully qualified host name and Kerberos domain as necessary.

ktadd -k /var/root/solaris_host_principals.keytab host/solaris.example.com@EXAMPLE.COM

Exit the kadmin.local tool by giving the command "quit".

For maximum security, export the keytab to a root-readable-only directory on an encrypted disk image.

9. Copy the /var/root/solaris_host_principals.keytab file to /etc/krb5/krb5.keytab on the Solaris system. Then, secure erase the /var/root/solaris_host_principals.keytab file from the Open Directory master.

You should now be able to get a TGT from the Open Directory master and connect to the Solaris machine using ssh without typing a password.

Slides from my preso are available at: <http://ps-enable.com/articles/WWDC2007Slides.pdf>


--Paul