Mac OS X Security

By Jesse Corbeil, Montréal Québec

Securing a Mac OS X workstation for stand-alone or home use out of the box

Note: Mac OS X is currently in Public Beta. The final version may invalidate any or all of this paper. That's just a chance we take when we write how-tos about beta operating systems

In the world of operating systems, the Macintosh platform has traditionally been everybody else's secure neighbour. Not many virii or cracks affected the Mac (unless we counted cross-platform Word macros), and we were generally spared the heaps of abuse that were laid onto our Windows-using brethren. Whether this has been due to the brotherly Mac community or the simple fact that there aren't enough Mac OS computers out there to make it worthwhile is up for debate. The truth will become clear when we all trash our old Macs and buy brand-new Cubes to run Apple's swank new OS. Why is that? Because Mac OS X is nothing more than a shiny interface on top of a tweaked BSD core, and BSD is very much slugging it out at the centre of the cracks and exploits blattleground. With that in mind, this article will discuss how to secure the default installation for a workstation or for home use.

BSD

Unix-cowboys have it all over us Mac users. They trade in the ease-of-use and smooth operation to which we are accustomed on the Mac side for raw, unlimited power over their machines. The easy Mac or Windows click-to-install approach is shunned in favour of the ability to tweak the code of an app that didn't install properly; cutting, thwacking, and generally forcing the code until the app clicks smoothly into place. Further, whereas we tend to troubleshoot by twiddling the knobs and banging the pipes, Unix-gurus crawl under the sink to pull the works apart. They know their machines better than we know our mothers.

Now, all that is about to change- at least for those of us who actually want to dig about under the hood and still enjoy the Mac OS experience.

With the change to Mac OS X, Apple reduces the number of major-player non-Unix OSes by one, while simaultaneously giving the Unix world something it has been trying to develop with imperfect solutions like KDE and Gnome: a distro with a polished and usable GUI.

What the BSD core (fetchingly called 'Darwin') gives back to the Mac is a rock-solid OS with all the buzz-technologies incorporated: multi-this, protected-that, and the new-to-Mac concept of an application crashing without taking down the OS. Unfortunately, what else we get is a security headache. Suddenly, all those Unix-savvy hacks and virii are mac-savvy too. Added to that (and I feel safe in going out on this particular limb), the country-bumpkin image that the Mac OS has enjoyed in hacker circles is about to be replaced by a perception of the OS as the sexy new Unix. Eager crackers will want to try out all the exploits and probe the nooks and crannies.

The Swiss-Cheese OS

Once they've been properly set up, the BSDs are generally pretty secure. They are developed by security-conscious communities and tend to be deployed in sensitive areas like networking and databasing. The Calgary-based OpenBSD is regarded as the most secure BSD distribution, incorporating many crypto and security features that would be non-exportable had it been an American distro subject to US export laws. Obviously, Apple could not have based Mac OS X in Open BSD and still sold the OS outside the US, but the more freely-exportable BSDs are still very secure, and the choice to base Mac OS X on the platform is still a solid one.

OpenBSD aside, any distro must be properly hardened to close up some of the dozens of holes left open by a default installation. This is where Darwin shows its BSD roots, and where a certain familiarity with Unix system hardening comes in. On a typical BSD system, one of the things an admin would do to secure the system is to edit the inetd.conf file to disable unneeded services. Mac OS X comes with the inetd.conf file already set up in a pretty secure configuration, but that doesn't mean that the OS is completely tight. There are other security holes in the default setup (such as services not covered by inetd.conf) that must be addressed before deploying the OS in a secured environment. When configuring services, the general rule of thumb is If you're not using it, turn it off.

There are some cool gewgaws in Mac OS X, though their default configurations can be pretty insecure. Running dmesg, for instance, reveals that there is an IP packet filter initialised but that it's wide open; The NFS daemon is active by default, which opens up a security hole, as does the Portmap daemon. There's an NTP daemon enabled, which opens a very slight security risk: though one wouldn't generally try to compromise the system through NTP, it is theoretically possible to muck about with it to make time-sensitive apps do one's bidding. But by far the coolest feature of the OS in terms of un-fubar-ability is the separation of admin accounts from the central, all-powerful root user. As part of the OS installation, I was asked to create an administrator account for myself. I set the system up as "jcorbeil," which is the account I generally use. From there I can administer just about anything on the machine - so long as the function is GUI accessible. However, if I try to enter rm -rf * in a Terminal window, the system will tell me to stuff myself. Why is this? It's due to Apple's approach to Mac OSX's design. Apple has made it as difficult as possible to hose your system by limiting GUI access to most of the really dangerous functions. That's a smart move on Apple's part, as it effectively stops non-gurus from inadvertently committing atrocities.

Another safety feature was revealed when I checked out the NetInfo application, which is where all system and user information is centralised. I discovered (and verified via a quick etc/passwd check) that even though my account is an administrator account, the system still pledges its allegiance to a separate root account that was automatically generated during installation. In other words, "jcorbeil" may be the system admin, but he doesn't have the same set of priviledges as the bonafide root user. To do something that only the root can (like erase the works), I have to su to root in Terminal, then do my damage. It's not hard, as the root account shares jcorbeil's password by default, but there's a certain level of know-how involved in getting to the 'destroy-the-OS' point that is beyond the ken of most new users coming from a classic Mac OS background.

To get a bit of an aperçu of what ports are open on your system, open a Terminal window and enter netstat -an (Figure 1). This will display your machine's ports and whether they are listening, established, or closed. If you want to see the ports' names, use the netstat -a command. It's a safe bet that you'll find ports you don't recognise. That's normal, but for for those who want to know all about ports, http://www.doshelp.com/trojanports.htm has some resources for the inquisutive firewall admin.

Chances are, you'll find two local addresses near the bottom of the list, called *.111 and *.514. These are our first two security issues. *.111 is portmap, which is a daemon for making RPC calls. It is also lousy for security, and is best turned off. *.514 is the syslog daemon, which listens on UDP and receives log broadcasts from other servers. Sounds pretty innocuous, right? Well, UDP is not a two-way protocol, so there's no way for syslog to verify whether or not the sender of a given datum is who he says he is, which opens up the potential for a denial of service attack. Nasty stuff. Tighten *.514 up by using IPF to stop connections other than 127.0.0.1 (more on this later).

After that, run a search for any files that are either world-writeable or owned by the "nobody" user or group. Every one of these opens up a little security hole, and should therefore be viewed with great circumspection. You might need a couple of them, you might not. Look about and clean up what you can by tightening up the access control to world-writeable files or files with 'nobody' ownership.

IPFilter: Built-in Security

IPFilter is a firewall that gets installed with the kernel, and is where some of the power of a BSD-based OS comes to the fore. IPFilter alone warrants a book or two, but there are some basics that everyone can use as a springboard to using IPF fairly quickly.

IPF works by processing a rules file. The rules file is a text file of conditions and actions for IPF to take when those conditions come to pass, for example blocking packets, letting packets through, and logging them. Set up IPF's rules file for blocking, passing, and logging based upon the criteria you want to employ. For example, say you don't want TCP packets coming in. You would edit the ipf.rules file by entering the following line of text:

block in on ed0 proto tcp from any to any

If you wanted the above to block only one port (say *.514), you would change the text to read:

block in on ed0 proto tcp from any to any port = 514.

Fiddle with the file, blocking and unblocking ports until you have a tight system from which you can still run the transactions you need. It is generally a good idea to start off your rules file with a command to block all ports. That way, any port that doesn't have a rule expressly attributed to it is covered by the first rule, and is blocked.

IPF is quite powerful, and it's a good idea to become well-acquainted with it. More in-depth information can be found at http://coombs.anu.edu.au/ipfilter.

Two things that I haven't touched on in this article are SSH and Kerberos. That has been done on purpose, as there is very little to be done with either of them for a home or standalone system set-up. SSH comes as part of the standard installation and is an extremely effective tool for keeping your system tight. For our purposes, you won't need to change the configuration. Just be serene in the knowledge that it's running and it has your safety in mind. Accordingly, you don't need to run services like rsh, telnet, rlogin, or ftp. They represent unneeded security risks, so unless you expressly need one of them for something, shut them down.

Kerberos uses a client/server setup, and you would only worry about Kerberos if you were on a network that uses the protocol. Since we're securing a home machine, we'll leave Kerberos alone.

Take it to the Bone

These solutions are not the be-all, end-all secret to how to secure your home system from a brilliant hacker, but they do form a solid foundation from which you can do further research into the methods and tools available to secure your computer. If you want to read further, check out the IP FilterFAQ at http://coombs.anu.edu.au/ipfilter/ipfilfaq.html, or read O'Reilly's Practical UNIX & Internet Security by Garfinkel and Spafford.

Whether or not you decide to delve into the deep, dark depths of computer security, a basic knowledge will still help you understand the basics. Basic knowledge will at least let you understand the theory behind a security breach that might nail your machine, and understanding will hand you the keys you need to get the problem fixed. Computer security doesn't have to be scary, indeed, it can even sometimes be fun. Getting caught unawares by a cracker, on the other hand, can cause you immeasurable pain.

Jesse Corbeil is the Director of Documentation at SecureOps, a network security consulting firm in Montréal, Canada. He has written for beoscentral.com and several other information sites, and is involved in the Marathon Open Source project.