« I don't understand | Main | All in all, it's just a »

So after having his Windows Server owned, Tom Yager writes up an article with the clickariffic title "Is Windows inherently more vulnerable to malware attacks than OS X?"

Right away, that title should warn you that regardless of what side it takes, it's going to have issues, and of course, this one does. Major issues, including stuff that is not "misinterpreted" but "wrong" as in "factually incorrect". Not that Tom is new to the "Let the headline do all the work so the article doesn't have to".

So, the Ugly:

Maximum privilege is extended only to descendants of process ID 1 (init or Darwin's launchd), a role that is rarely used and closely scrutinized.

Unlike services.exe, launchd executes daemons and scheduled commands in a shell that's subject to login scripts, environment variables, resource limits, auditing and all security features of Darwin/OS X.

Apple's daemons have man pages, and third parties are duty-bound to provide the same. Admins also expect to be able to run daemons, with verbose reporting, in a shell for testing. • OS X Man pages document daemons' file dependencies, so administrators can easily rework file permissions to match daemons' reduced privileges.

"AUTOFSD(8) BSD System Manager's Manual AUTOFSD(8)

NAME
autofsd -- daemon to update autofs mounts on network changes

SYNOPSIS
/usr/libexec/autofsd

DESCRIPTION
autofsd runs automount(8), and then waits for network configuration change events and, when such an event occurs, re-runs automount(8) to
update the mounts to reflect the current automounter maps. It can also be signalled by automount_reread(8) to run automount(8).

SEE ALSO
automount(8), automount_reread(8), automountd(8), configd(8)

Darwin July 13, 2006 Darwin"

I'm not seeing a lot of information on dependencies here, unless by "Dependencies", Tom means "other files referenced by the man page". Note: they aren't the same, especially when out of the four other executables listed, three of them are somewhat dependent on autofsd. Oh, how did I know to check that one? I didn't. it was the first daemon in the list. I just know more about man pages than Tom does. "Duty bound"...BAAAAHAHAHAHAAHAHAHA.

Launchd can tripwire directories so that if they're altered unexpectedly, launchd triggers a response.

Yes, it *can*. It doesn't by default, and if you want to set that up, you have to set up a new launchd item for each directory. And what are most of those going to run as? Yeah. root.

If an attacker takes over a local or remote console, any effort to install software or alter significant system settings cannot proceed without entering the administrator's user name and password, even if the console is already logged in as a privileged user. In other words, even having privileges doesn't ensure that even an inside hacker can arrange to keep them.

Le Sigh: So install a background keylogger that only runs in the user context you took over the shell for. With Apple's "AUTHENTICATE FOR EVERYTHING INCLUDING ADDING A PRINTER" mindset in Mac OS X 10.5, and probably later, you'll get an administrator password soon enough, and once you have that, you have access to root. Whee!

Applications have their own per-user and system-wide properties files, private Registries if you like, stored in human-readable files in standard locations.

Tom missed the memo on binary .plist files that aren't so human-readable anymore.

Every installed file is traceable to a bill of materials that can verify that the file is meant to exist, and that it and all of its dependencies match their original checksums. Mac users, back up and protect your Receipts folder!

Other applications I use that don't have receipts?

Every Omnigroup application on my system
Twitteriffic
Firefox
Script Debugger
FaceSpan
Transmit

and every other application I install via Drag and Drop.

The other myth Tom works in here is the one (STOP LISTENING TO MACFIXIT) that somehow the OS will "verify" third party applications on the Mac, and "fix" the permissions if they change. That's a huge myth, and it needs to end. Fixing permissions only applies to Apple software, and only a specific list of those. Apple is not going to change permissions on third party software, even if they are different from what the Receipt says, because that would be stupid. Apple doesn't even check all of its OWN software, because there's nothing wrong with having different permissions for *iTunes* than what it shipped with. In fact, altering permissions on certain applications is common when you don't want to delete it, but you don't want everyone to have access to it. Tom's wrong as hell here.

OS X does not require that a user be logged in as an administrator to install software. The user or someone aiding the install needs to know the name and password of a local administrative user to complete the install. On a network, most software is installed using Remote Desktop, an inexpensive Systems Management Server-like console.

The UNIX/POSIX API, standard command-line tools and open source tools leave malware unable to hide from a competent OS X administrator. It takes a new UNIX programmer longer to choose an editor than it does to write a console app that walks the process tree listing privileged processes. Finding the owners of open TCP/UDP ports or open files is similarly trivial. The "system" is not opaque.

Evidently, the concept of providing nearly identical binaries with altered contents doesn't exist for Tom. As well, I can find out the same information on Windows pretty trivially too, you just have to know what you're doing. Windows is only OMG OPAQUE if you're ignorant. It's not as transparent as Unix, but it's not a monlith teasing the monkeys either.

Basic OS X features can be put to use to make life miserable for malware. For example, Windows' hackable restore points are done better by OS X's ability to create encrypted, read-only disk images. They're simpler than archives, and you can mount them as volumes anywhere in your file hierarchy.

Likewise, OS X Server will image any Mac client or server's local drives and maintain safe copies that can be used not only for restoration, but which can be booted from to guarantee that there's no trace of infection.

Oh hell, I can't go on, the stupid makes me cramp. Look, there are a lot of good reasons to use Mac OS X. There are lots of good reasons to use Windows. Both, especially current versions, are, when properly maintained secure. But don't use magical thinking like the crap in Yager's article as a reason.

Comments