Mac OS X Security
Volume Number: 17
Issue Number: 4
Column Tag: Mac 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.
Openings and Closings
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.
Figure 1. What comes up when you type netstat -an
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.
SSH and Kerberos
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.