Recently we have seen several interesting developments in Mac OS X Security. Apple published a Leopard Security configuration guide (pdf) for experienced Mac OS X users. Apress published Foundations of Mac OS X Leopard Security. (Slashdot review here.)

However, I think the most interesting development has been the discussion of a SUID vulnerability by Matasano Chargen, among others. The vulnerability can be easily fixed by:

sudo chmod -R u-s /System/Library/CoreServices/RemoteManagement/ARDAgent.app

Along with the announcement that most of the work on the next version of OS X will be under-the-hood improvements, the discussions of what improvements Apple should make to OS X Security have been thriving. In particular, I like Dino Dai Zovi’s editorial on what improvements he would make.

Dino lays out five specific improvements he would make:

  • Real ASLR (address space layout randomization). Library randomization with dyld loaded at a fixed location just doesn’t cut it.
  • Full use of hardware-enforced Non-eXecutable memory (NX). Currently, only the stack segments are enforced to be non-executable. Welcome to the new millennium where buffer overflows aren’t only on the stack.
  • Default 64-bit native execution for any security-sensitive processes. I don’t particularly care that it may waste 5% more memory and a little bit of speed, I want Safari, Mail.app and just about everything else that has security exposure to run as a 64-bit process. Simply because function arguments are passed in registers rather than on the stack, this makes working around ASLR and NX damn near impossible for many exploits.
  • Sandbox policies for Safari, Mail.app, and third-party applications. Code execution vulnerabilities aren’t the only kind of vulnerabilities and good sandbox policies for security-exposed applications can help mitigate the exploitation of code execution and other vulnerabilities in these applications. I love the scheme-based policies, by the way.
  • Mandatory code signing for any kernel extensions. I don’t want to have to worry about kernel rootkits, hyperjacking, or malware infecting existing kernel drivers on disk. Most kernel extensions are from Apple anyway and for the few common 3rd party ones, they should be required to get a code signing certificate.

Overall, this is an excellent list with one glaring omission: improve FileVault. There are many things that could be improved in this area, but I think the first two that come to my mind are integration with Time Machine and the ability to configure encryption for individual folders (other than the home folder) or entire disks. There are other, more technical problems with FileVault (such as the use of CBC mode encryption), but I think these are largely less important than living up to Apple’s reputation for making things easy to use. Right now, FileVault is not easy to use with Time Machine and it doesn’t serve the needs of those who need full disk encryption or those who really only want a few folders to be encrypted.

I would also like to pick a tiny nit on Dino’s list. I think Mandatory code signing for kernel extensions should be something that by default is enabled, but could be turned off manually as a part of the System Preferences by a user. There are still people who want the freedom to do whatever they want with their computer and although this may mean that they have enough rope to hang themselves, they still deserve that freedom.