Page 8
<<Back | Index | Next >>

Macintosh Security Basics - Presentation Notes

Test it

Play the hacker. Symantec can scan your machine and generate a report


• Multiple Users
• Non-passive-mode FTP connections
• Allowing for non-obvious traffic (e.g. Keyserver)
Test your firewall settings. Play the hacker. Symantec has a URL you can visit which scans your machine and generates a report about its level of security. Keep in mind that if you’re NAT’ed, it won’t work, and if you’re behind a firewall, your security administrator may hate you for doing this.


• If you’re using Multiple Users, you’ll need to make sure that your fw offers the proper amount of protection for all users. NPF uses one Prefs file for all users but other fws may not.

• Beware of non-passive-mode FTP connections, often characterized by a connection drop at 99 percent download completion. (It’s like they TRIED to make it as frustrating as possible.) Set Passive Mode under Fetch’s “Firewall” Preferences tab.

• If email takes forever, it may be an AUTH thing. Either allow the traffic (TCP/113) or do an explicit reject so it doesn’t do the long timeout in response to a silent drop.

• PTP programs (Gnutella and such) may malfunction in the presence of a firewall.

• If you block UDP access on high ports, it may mess up DNS. Also don’t block UDP/68 if you use DHCP to get an IP address (at Dartmouth, this is the standard method). Ideally you need only allow that access from the IP of the DHCP server, but if you’re not sure, open that port to anything. It’s a pretty minor security hole.

•If you use NTP for Date and Time, open up UDP/123 from the specified NTP server.

• If you use Keyserver over IP, it needs UDP/19283. You probably use it over AppleTalk, though (default).


Everything’s changed.

OS X is based on a Unix subsystem, a version of FreeBSD called Darwin. Here’s a pictorial representation of the OS:)

(Don’t worry about the GTK/Xdarwin part.)
To maintain backwards compatibility with the existing library of Macintosh software, Mac OS X integrates the new Unix-based environment with a MacOS-based emulation environment called “Classic” (also sometimes called the True Blue Environment, which is how it shows up in top). Old Mac apps run within Classic, and Classic runs within X. As far as X is concerned, Classic is just another application. It can be killed like any other Unix app, which is nice for those times when some Classic app crashes the environment.

The term “Carbon” is used to describe applications which are written such that they can run natively in either OS X or Classic/OS 9. This is similar to “fat binary” apps (which existed during the transition from the 680x0 processor to the PowerPC processor -- some software was re-written to include code for both processor types, and since this tended to make them bigger, they were called “fat.”) If you Get Info on a Carbon app, you can toggle a checkbox to tell the app whether to launch in OS X or in Classic. “Cocoa” describes apps written specifically for OS X, and which will not run in OS 9. Platinum and Aqua are the names Apple uses to describe the user-visible appearance of the operating system. Think of them as Winamp skins. Classic always wears the Platinum appearance, which among other things, describes the shape and size of common elements like scroll bars and title bars and menu fonts. Similarly, Aqua is the skin worn by OS X, and it describes things like translucency of background windows and drop shadows and such.

MAC OS X Continued

QuickDraw and Quartz are the respective underlying graphics “engines” which are what drive the appearance of the OS. I’m not sure if it’s still the case today, but originally, most if not all of the Mac’s QuickDraw calls were hardwired into the ROMs, which is why all Mac apps tended to look very similar; things like title bars and menus and the shape of the cursor were standard objects. This was very deliberate on Apple’s part -- it was a big part of what made the Mac easy to use for newbies, because so much of what you learned about one app could be applied to all the others.

The light-gray column in this picture shows the “command line” riding on top of the Terminal window, which in turn sits above the Shell. IMHO this doesn’t really serve to illustrate much -- all you need to know is that if you want to get at the Unix command-line interface, you first have to open a Terminal window (Terminal is the name of the app that gives you CLI access). By default, your shell is tcsh, though it’s easy to add bash if you prefer it.

The far-right column has to do with a nifty add-on (NOT part of the OS, whereas the rest of the picture is) called XDarwin, which is the Unix XWindows environment for OS X. This may seem incredibly redundant, but it allows you to do some very cool things that you wouldn’t otherwise be able to do. It’s outside the scope of this class, but blitz me if you’d like a demo.

Macs and Unix

OS X inherits from NeXTStep and Rhapsody

What you get:

• Memory protection
• Preemptive multitasking
• Built-in compiler
• etc. -- all the coolness of Unix

Combined with:

• Really terrific UI that Macs are famous for
• BUT: We gave up uniqueness. Vulnerabilities that affect BSD Unix can now affect Macs, too.
OS X inherits much from NeXTStep and Rhapsody. See handout # 3, “Mac OS X System Administration,” for more about the history of NeXT and OS X.

OS X is the best of both worlds. It has all the functional advantages of Unix, like memory protection, preemptive multitasking, the built-in compiler, Unix compatibility resulting in access to a huge library of software (even the Debian apt-get tools have been ported to OS X), Darwin is open-source so more software’s coming faster, etc. AND...

…it has all the user-interface advantages that the Macintosh is famous for. Most Mac users never need to interact with the Unix-ness directly; they just revel in the delight of using a Mac that (almost) never crashes.

• The price we pay for this: We’re not unique anymore.

Vulnerabilities that affect BSD Unix, Apache, OpenSSH, etc. can now affect Macs, too.

There can be many

OS X is a multi-user system.

Administrator is not quite root, but almost

• Sudo is invoked when needed in the GUI
• It can also be used explicitly at the CLI, just like in any other

Unix Administrator has enough privileges to do just about anything you need.
Unlike old MacOS, OS X is a multi-user system. When you first set up your new Mac, you are asked to provide a username and password for the Administrator account. Administrator is not root, but it’s almost that powerful -- Apple hides root from you, for your own safety, and invokes something much like sudo when you need to do root-esque things.

At first I didn’t understand this -- I thought, “this is MY computer, I should be able to do ANYTHING I WANT.” So I performed the convoluted hack to enable root login (this was OS X 10.0, it wasn’t easy) and I habitually ran things while logged in as root. One day, I went to change modes (chmod) a file, but I didn’t notice that I’d accidentally selected the whole hard disk (I was still getting used to OS X), and it seemed to be taking awhile to finish…spinning beach ball of doom…uh-oh. I’d recursively chmod’ed every file on the disk. OS X never booted again. I had to boot into OS 9 to get my data, then wipe the drive and start over.

The moral of the story is, that wouldn’t have happened if I hadn’t insisted on being root all the time. OS X would’ve chmod’ed maybe one folder’s worth of stuff, but it would’ve stopped before it reached the core system files and tossed a dialog saying “you don’t have permission to do that” or something similar.

Administrator has enough privileges to do nearly anything you’ll need to do -- you don’t need true root unless you start really messing around with the Unix guts of OS X. Even then, it’s HIGHLY recommended that you use sudo, rather than enable the root password and stay logged in as root for long periods of time. You’re far less likely to do irreparable damage to your system if you use sudo, since it gives you root privs only on a per-command basis. Metaphorically, you’ve only chambered one round at a time, and if the gun goes off, at least it’s not on full auto. ;)

Very rarely will sudo fail to meet your needs. But once in a while, something in a shell script or some hardcore tinkering will require true root. The easiest way to go at it in that case is sudo su - and use your Administrator password. You will be root, with root’s path.

Users and Folders

You can create users, and choose whether or not to give them Administrator rights

Each user has a home folder (under /Users)

Each user also has a “Desktop” folder, which corresponds to the desktop he or she sees.
You can create however many users you want, and you can give them Administrator rights (they can do Admin-level stuff using just their own passwords for authentication, like sudo) or leave them as normal, non-admin users. Each user has a home folder (under /Users) which stores his/her documents, preferences, fonts, personal webpage (if you have Web Sharing enabled), etc. If you do NOT give users admin rights, then they can only make new files in their home directories. They can still run applications that reside outside their home folders, but apps that need root (say, a sniffer) will not work for them. This should be quite familiar to Unix users.

Each user also has a “Desktop” folder, which corresponds to the desktop he or she sees. It shows up as a folder called Desktop in your home directory, but it’s simultaneously also the desktop underneath all your windows (which can get weird, since you can open the Desktop _folder_ and be looking at the icons that are also on your visible Desktop.) This is quite different from the Desktop of old MacOS, which was sort of an über-folder. Each user can put different things on his or her Desktop, and other users won’t see them -- they’ll see their own Desktops.

Note: Users ought to make use of the screen saver lock feature -- it requires you to enter your password to unlock the screen saver. System Preferences -> Screen Effects. And never turn on the auto-login feature unless you’re sure your Mac is physically isolated from other people; also, it’s better to leave off the “pick user from list” option and type your username. Again, don’t make it easier for the bad guys.

Users and Apps

Users can install their own applications

If they have Admin rights, they can install apps available to all users

In general, applications run with the privileges of the user who launches them.
Users can install their own applications, available only to them, or (if they have Admin rights) they can install apps available to the whole system.

For the most part, applications run with the privileges of the user who launches them. In other words, if I open BBEdit and try to edit the /etc/hosts file, BBEdit will ask me to authenticate as Admin with my password before I can save changes. (This assumes that my account has Admin rights, or in more Unixy terms, I am in the sudoers list.) Users who are not flagged as Administrators would not be able to edit that file at all.

BSD File Security

Same as any Unix -- owner, group, everyone, modes, etc.

Can be changed at the CLI using the usual -- chmod, chown, etc. -- as well as with the GUI Get Info.
As with any Unix, files in OS X have access restrictions based on owner and group, and files have modes (r/w/x). This isn’t just the case for network file sharing (as is true with pre-X Mac OS) -- it’s also true for every file on the system. Old news for Unix folks, but a new realm for Mac users.


When you open an old Mac app, OS X first launches the Classic (“TrueBlue”) environment, then opens the app within that The integration is fairly seamless -- some menus change, but you always see the OS X Finder/Desktop and the Dock If some Classic Mac app crashes, it’ll probably take the Classic environment down with it, but OS X keeps running :)
To maintain compatibility with old MacOS software, Apple developed a MacOS emulation environment, called Classic. When you open an old Mac app, say, Classic Netscape, OS X first launches the Classic (“TrueBlue”) environment, then opens Netscape within that. The integration is fairly seamless -- some menus change when you flip between OS X and Classic apps, but you always see the OS X Finder/Desktop and the Dock.

Classic runs as a separate process under OS X -- Classic is, in effect, just another application under OS X. The cool thing about this is that when some Classic Mac app crashes (that would NEVER happen! hah), it’ll probably take the Classic environment down with it, but OS X keeps running happily. The miracle of memory protection.

(In the beta release of OS X Server, Classic and X were integrated differently, and it was possible for Classic to crash and take the input devices with it. OS X would still be running, but you couldn’t reach it to kill Classic -- your cursor was frozen, keyboard locked. But, you COULD shell in from another machine and run ps, find the Classic process, and kill -9 it and get X back. Nice.)


• The integration is fairly seamless. Not completely.


• Both Classic and OS X use a single IP address
• File sharing weirdness
• Both environments can share a printer
• OS X owns the CD-ROM and Zip drive
• Only one Finder (X)
• OS 9 Desktop is still separate from OS X’s
The integration is _fairly_ seamless. It still takes a lot of getting used to, especially if you’ve been a Mac user for awhile.


Both Classic and OS X use a single IP address. It doesn’t affect client-type behavior (e.g., you can use a web browser in each environment simultaneously), but it can get weird with running servers.

You can’t do file sharing under Classic under X anymore (but you could do it with AppleTalk only, no AFPoverTCP, in OS X 10.1, WHILE you were sharing files directly from X too. Schizophrenic.) You can’t connect to AppleTalk-only servers from Classic, but you can from X. You CAN do Program Linking from within Classic, God only knows what happens if try to do Apple Events in X at the same time. (It seems to let you turn on both simultaneously…)

Both environments can share one printer (need drivers for each environment, except for the occasions when Classic just seems to “learn” about the printer from X), but OS X owns the CD-ROM and Zip drive.

There is only one Finder (in X).

The Desktop of Mac OS 9 is a separate entity from that of OS X, and under OS X, it’s invisible in the Finder (but you can see it from the Terminal if you list the contents of the / directory). When you install OS X, it automatically creates an alias to the Mac OS 9 Desktop, and puts that on your OS X Desktop (stay with me here) and if you delete it, like I did, then you’re sorta locked out of your OS 9 Desktop. But don’t worry, it’s still there if you boot into 9. (More on that in the next slide)

More on Classic/X

More: Under the standard partitioning scheme, you can boot directly into MacOS 9

• This has scary implications for file permissions

Carbon apps will run in anything, which is good to know

OS X “packages” (app bundles) will appear as folders in 9, don’t mess with the contents!
Oh, and as if that’s not enough, you can tell the Mac to boot directly into MacOS 9 (using the same System Folder as Classic), and then OS X effectively disappears and you have an old-school Mac again. This also has the side effect of making most of the Unix file permissions moot -- in other words, if you boot into 9, you can probably delete the /bin directory REGARDLESS of your OS X Administrator status, because regular MacOS doesn’t speak that language. There isn’t a complete disregard for it, though. Some key files and directories from OS X will be “grayed out” in the Finder if you boot into MacOS 9. But…from a Save or Open dialog in some applications, you can still see and modify everything. Mac OS 9 is gradually being phased out, but in the meantime, all you can really do is shrug and be careful.

Remember the Carbon thing? Those apps will run in OS X, or in Classic, or in OS 9 directly. So? Well, if you make a bad mistake like I did, and hose your OS X system, you can (hopefully) still boot into OS 9. You can grab your original CD and boot off it long enough to change the Startup Disk setting and reboot 9. Then, if you held onto some Carbon (or Classic) apps, you can go in and run them from 9 and perhaps use them to recover your data. It’s nice to have a copy of Fetch that will work in either environment -- I used it to move my data onto a network file server when I did the Bad Chmod that time. In short: If you’ve got the disk space, it’s a good idea to hang onto Classic/Carbon apps even after you install a superior Cocoa equivalent, so you double your chances of being able to recover from a bad event. If you’re in 9 and you want to know whether some app will run or not, you can just try it, and you’ll get a message if it’s Cocoa. In general, if the application icon appears properly in 9, it’s probably Carbonized.

One other note: OS X Cocoa apps sometimes make use of “packages,” which are essentially application bundles -- they will appear as a single icon that you double-click to launch, just like any other app, but if you control-click them, you can see and alter the contents. Sort of like using ResEdit in the old days to hack the resource fork, only now you don’t need a separate tool. But if you boot into OS 9, packages will appear as folders since OS 9 doesn’t know what packages are -- don’t start adding or removing things from them, because when you boot back into OS X, they might not work right anymore!

OS X Security “out of the box”

Is pretty good.

If I turn off my firewall and run TCP and UDP portscans against my Mac, here are the results (notes sections):

I can explain what I see. Nothing mysterious. This is important.

I haven’t done any low-level hacking to turn off default services, so a base OS X install should have fewer open ports than what I have.
Results of nmap -sT -p 1-65535 my-mac (that’s a plain vanilla TCP scan of all ports):

Starting nmap V. 2.54BETA31 ( )

Interesting ports on my-mac (some.ip.address):

(The 65530 ports scanned but not shown below are in state: closed)

Port State Service

22/tcp open ssh

80/tcp open http

427/tcp open svrloc

548/tcp open afpovertcp

902/tcp open unknown

913/tcp open unknown

2151/tcp open unknown

We know what the first two are. I’m running SSH (“Allow remote login” is turned on in Sharing) and I’ve got Web Sharing turned on. 427 (svrloc) is the Server Location daemon/protocol, which helps my Mac and other Macs find each other’s services on the network. Port 548 shows File Sharing enabled (over TCP, default on OS X, though I can enable AppleTalk as well). Nmap didn’t know what port 913 is for, so I Googled for “port 913” and discovered that it’s the Sidecar port (part of Kerberos, which we use to access protected portions of the Dartmouth website, among other things). Ports 902 and 2151 are for my BlitzMail ssh tunnel. If I hadn’t already known that, it’d be kinda hard to figure out, since BlitzMail is a Dartmouth thing and Googling for those ports will get you a lot of nonsense. But I could’ve tried telnetting to those ports…

What is THAT port?

bash mbates@my-mac ~ $ telnet localhost 902

Connected to localhost.
Escape character is '^]'.
220 DND server here.

Aha! Unfortunately, the same trick for 2151 is a lot less informative.
bash mbates@my-mac ~ $ telnet localhost 2151


Connected to localhost.

Escape character is '^]'.


011 Unknown command: hell


011 Unknown command: helo


011 Unknown command: help


013 Missing argument.


011 Unknown command: info


011 Unknown command: get

(I gave up and exited)

Heh. But, a logical next step might’ve been to search the Dartmouth Computing Services webpages for info on what ports BlitzMail uses.

More on ports and services

• lsof -i shows ports and their corresponding services

• You can get this with netstat, but lsof is a little easier to read and interpret


automount 260 root 4u inet 0x01bb8970 0t0 UDP *:860
httpd 268 root 16u inet 0x01d33cdc 0t0 TCP *:80 (LISTEN)
httpd 270 www 16u inet 0x01d33cdc 0t0 TCP *:80 (LISTEN)
sshd 283 root 3u inet 0x01d33a2c 0t0 TCP *:ssh (LISTEN)
slpd 293 root 0u inet 0x01bb8560 0t0 UDP *:427
slpd 293 root 1u inet 0x01d3377c 0t0 TCP *:427 (LISTEN)
Results of nmap -sU -p 1-65535 my-mac (same as before, but UDP ports this time):

Starting nmap V. 2.54BETA31 ( )

Interesting ports on my-mac (some.ip.address):

(The 65526 ports scanned but not shown below are in state: closed)

Port State Service

68/udp open dhcpclient

123/udp open ntp

427/udp open svrloc

514/udp open syslog

860/udp open unknown

49152/udp open unknown

49155/udp open unknown

49158/udp open unknown

49160/udp open unknown

68 is for my Mac to get an IP address from the DHCP server on my network. 123 is ntp, Network Time Protocol -- my Mac syncs its clock with Dartmouth’s NTP server. 427 is the UDP port for svrloc, explained on the previous slide (svrloc uses both TCP and UDP). 514 is syslog appearing to listen on the network, but it doesn’t actually accept data from other hosts. 860 is automounter listening for other hosts’ nfs requests, which is moot since I don’t have any nfs shares defined. 49152 is being used by Keyserver, and I can’t telnet to it (connection refused), so how would I know? I cheated and used lsof. (Could’ve done that before too, but I wanted to show you another way to figure out what ports are used for which applications.) The last three ports are being used by lookupd, the all-purpose lookup daemon (for DNS among other things) and again, I used lsof to figure that out.


Via syslog. Look in /var/log system.log is a good place to start

• Firewall logs (seems buggy, at least with BrickHouse -- sometimes stops???)
• Use of sudo
• Subsystem status messages

also, /var/log/httpd/access_log and error_log

others for other services (ftp, mail, etc.)
OS X logs via the Unix syslog facility. There may be some nice GUI log

reader available, but your best log analysis tools are grep and/or a good text

editor with a Find function. E.g.:

grep sudo /var/log/system.log # Look for all instances of sudo

tail -f /var/log/system.log | grep something # Watch the log as it’s written (-f # = “follow”) and pipe the output # to grep to look for “something”

grep -v <your-ip> /var/log/httpd/access.log # Inverse grep (look for # everything BUT your-ip)

And so on.

Unix and Mac can collide…

VHFS+ is the native/default file system for OS X

OS X also supports UFS (Unix File System)

One big difference:

• HFS+ preserves case of file names, but is case- insensitive (filename = FileName = FILENAME)

• UFS is not! Those could be three separate files

• Implications?
Sometimes the Mac-ness and the Unix-ness of OS X really butt heads.
HFS+, the Mac’s native file system since approximately MacOS v. 8, is a case
preserving but case-insensitive file system. This means that, under HFS+, a
file called “goober” cannot exist in the same folder as a file called “GooBer”
or “GOOBER” etc. Those are all considered to be the same name. But, under
UFS, which is also supported by OS X, case DOES make a difference; UFS
would consider all of those to be separate file names. Well, so what?

Apache vulnerability!

“CERT/CC Vulnerability Note VU#439395 Apache web server performs case sensitive filtering on Mac OS X HFS+ case insensitive filesystem...

...Impact: Can bypass Apache file access protection, allowing remote unprivileged users to read privileged files.” Yikes!
THIS is what:


CERT/CC Vulnerability Note VU#439395

Apache web server performs case sensitive filtering on Mac OS X HFS+ case insensitive


I. Description: The Apache web server's file access protection scheme (i.e., file request

"filtering") assumes that the filesystem being protected is case sensitve...

Under the Apache scheme, you specify whether to deny or allow access to a filesystem object

(which can be a directory, filename, or URL). The specifications are called "directives", which

include <Directory>, <Files> and <Location> directives. See
for further information on directives.

When you use a directive to deny access to a file or directory using the Apache web server

under Mac OS X HFS+, the directive will NOT deny access to any other upper and lower case

variation on the filename or directory...


OOPS! Some tweaking in the Apache config file could fix this, and Apple

released a patch right away, so it’s not an issue now. But this serves to

illustrate how programs which are accustomed to Unix/UFS behavior can

potentially be tripped up by seemingly-subtle differences like that.

For more details on this vulnerability and its solutions, go to:

Ease of Use

OS X is much more server-oriented than old MacOS

All sharing-related services are handled from a single Preference pane

• One click turns on file sharing
• One click turns on FTP access to shared files
• One click turns on Web Sharing
• One click turns on SSH access

Even more important: One click turns these OFF!
OS X, even the non-”Server” version, is much more server-oriented than old MacOS. Most of its server functionality can be turned on or off and configured through the Sharing preference pane. The defaults for most services are well-thought-out and are sufficient for most users’ needs.

In the Sharing preference pane, all of the following services can be turned on or off, and tweaked:

• File sharing

• FTP access to shared files (yikes…)

• Web Sharing, which uses the tried-and-true Apache web server -- root web dir is Admin-access only, and each user has homepage folder (http://.../~username)

• Remote shell access - using OpenSSH, not telnet!

• Remote Apple Events (formerly known as Program Linking)

Likewise, one click turns these OFF, which is important when a vulnerability in Apache or OpenSSH is discovered. As of OS X 10.2, the Sharing pane also includes a GUI to administer the firewall. From what I’ve seen, it seems pretty minimal...I’d still recommend BrickHouse, which we’ll talk about soon.

A note: These service startup settings are written to a file, /etc/hostconfig. You can edit this file directly to turn services on/off at startup. Good to know if you want to shut down a service when you’re not sitting in front of the Mac (i.e., do this over SSH).

<<Back | Index | Next >>