Apple

Anti-Virus Options for OS X

I'll give you the executive summary ("TL;DR") version right up front: the world of anti-malware products for OS X is pretty awful.

Most products are re-cycled from their Windows counterparts and don't feel like something made for OS X. Many products destabilize the OS or have a heavy impact on CPU. Worst, many have vulnerabilities themselves, making you feel secure for having installed them, but in reality making you less secure.

Then, there's just plain foolishness. While evaluating the state of current A/V for OS X, I tried to get a trial of Symantec Endpoint Protection for Mac. After spending time on the website, and figuring I was just missing how to download it, I chatted with a sales rep. No, he assured me, I wasn't just missing it: there is no trial for the Mac. "Can't be," I thought.

The good news: there is a Mac client.

The bad news: you need to download the Windows version of the product, which weighs in at 1GB. It's a Windows .exe executable file. Or is it?

The Windows app is really a 7zip executable, so you can unpack it with The Unarchiver on your mac. This reveals a "Symantec_Endpoint_Protection_12.1.2_Part1_Trialware_EN" folder. Inside that archive at the path SEPM/Packages/, you'll find SEP_Mac.dat. Rename it to SEC_Mac.zip and again use The Unarchiver to unpack this and you'll get a new folder with the installer.

Why the obscurity?

Possibly the worst part of the whole experience? Symantec recommends that you use their Java-based download manager to download the file. Yeah, Symantec is truly concerned about security.

PSU MacAdmin Handout

I'm giving a presentation at this year's Penn State MacAdmin Conference. So people can pay attention and don't have to scribble notes, here's a complementary document that contains notes and links to everything I talk about in the presentation.

http://radiotope.com/f/PSU2012-Logs%2C%20Damn%20Logs%2C%20and%20Statisti...

Updated[2]: For Security's Sake: Remove Diginotar CA Certificate

*
Apple has released a security update for Snow Leopard and Lion that addresses this issue:

Snow Leopard: http://support.apple.com/kb/DL1446
Lion: http://support.apple.com/kb/DL1447

There is no update for Leopard, so, in that case, you should still follow the instructions below.

Apple's update simply drops these files into place (on Lion):

/System/Library/Keychains/EVRoots.plist
/System/Library/Keychains/SystemRootCertificates.keychain
/System/Library/Keychains/SystemTrustSettings.plist

So, no matter which updates you made to the Diginotar cert -- delete or untrust -- the Apple update will just plow over all of that with the right setting and updated certs.
*

While ignoring how broken the entire Certificate Authority (CA) model is, here's what you should do right now: Delete the CA cert for Diginotar from your system. Why?

http://www.computerweekly.com/Articles/2011/08/30/247730/Microsoft-warns...

Now, if you're an individual, this is simple: just remove it from your system. Since I largely focus on Macs here, that would be in the keychain. Open Keychain Access.app, search for "Diginotar" and delete the resulting certificate.

...and don't forget Firefox, which keeps its own list of CAs:

http://support.mozilla.com/en-US/kb/deleting-diginotar-ca-cert

But, what if you're a Sys Admin responsible for protecting a fleet of machines and you don't expect end-users to do this themselves? (Or, that you're going to personally visit each machine.) Automate it, of course! The security binary will help you do that:

sudo /usr/bin/security delete-certificate -Z C060ED44CBD881BD0EF86C0BA287DDCF8167478C /System/Library/Keychains/SystemRootCertificates.keychain

(You can first check for the existence of the certificate using security's find-certificate instruction.)

Of course, you're using a system management framework that will allow you to run this command on all the machines in your fleet, right?

Update: This turns out to be a little more complex than simply removing the certificate. While removing the Diginotar cert is still recommended, DigiNotar is cross signed by other CAs. Removing the Diginotar root only removes one of them (and there are 5 paths). Also, it seems that there are some bugs in Apple's certificate handling in some cases. So, what can we do?

Certainly, remove the Diginotar cert from your machines, as that does help the most egregious cases. From there, we have two options: Use FireFox 6.0.1, which uses its own root certificate store and is now protected against this. Secondly, we need to wait for a patch from Apple--the only one in a position to really address this. Only a patch from Apple can completely fix browsers and apps that rely on the system store, Safari, of course, being the biggest use case, with Chrome and Mail.app as two other Webkit-based apps that may rely on the system root store for certificate handling.

(Big thanks to Harald Wagener for review on this, and reminding me about using find-certificate.)

Dumping the Dropbox Database

A while ago, I wrote a quick script to dump the database that Dropbox uses to store its config info. I use this in my .bash_profile script mainly to locate the Dropbox folder on any given machine I'm on. If you're curious as to what's getting stored, I've attached the script here.

Reset Apple Software Update Service (SUS)

Honestly, there's no more finicky service under OS X Server than Software Update. Sometimes, you just need reset the service and start from scratch. Under Server 10.6, the best way I've found is to:

- Stop the service.
- Get a shell on the server and sudo up to root.
- mv /var/db/swupd /var/db/swupd.old
- mv /etc/swupd /etc/swupd.old
- mkdir -p /var/db/swupd/html
- chown -R _softwareupdate:_softwareupdate /var/db/swupd
- chmod g+w /var/db/swupd
- Use ServerAdmin to (re)set the preferences for the service
- Let 'er rip. (start the service)

New 11.6" and 13" MacBook Air Compile Benchmarks

This is a super-simple benchmark of compile times on the new 11.6" and 13" MacBook Air machines. I downloaded Adium 1.4 and ran time make in the top-level directory. The 13" MacBook Air model was the base 2GB model, while the 11" was the higher-end model with the faster CPU and 4GB of RAM. Both machines were freshly booted with no other software running besides Terminal.app.

13" MBA

Hardware:
Hardware Overview:
Model Name: MacBook Air
Model Identifier: MacBookAir3,2
Processor Name: Intel Core 2 Duo
Processor Speed: 2.13 GHz

WebKit Web Inspector Anywhere

Pretty awesome utility: most people know that you can pull up a web/javascript debugger under Safari. But did you know that you can expose this on (nearly) any WebKit frame? Try this:

defaults write -GlobalDomain WebKitDeveloperExtras -bool true

...and then launch (or, quit and relaunch) any app that exposes a WebKitUIView. Right-click on the WebKitUIView and choose "Inspect Element" - Bingo! Up pops the WebKit web debugger.

Now, some applications block this ability unintentionally, or sometimes very intentionally (Mail.app, I'm looking at *you*).

Managed Prefs Presentation in NY

I've been meaning to mention: I'll be giving a talk about Macintosh managed preferences (related to the book) at the monthly Tri-State Chapter of the Apple Consultants Network.

This takes place on the 2nd of September at 6pm at Novaworks in NY. If you're an ACN member, I hope to see you there. If you're not and would like to attend, ping me via e-mail.

Mac Enterprise Managed Preferences Book Released

My book on Managed Preferences for Mac OS X has been released (Amazon Link).

Reading Safari's LastSession.plist

Is it just me, or does everyone see this message when quitting Safari:

"Do you really want to Quit Safari? You have a 400 Windows open that contain a bajillion tabs!"

Yeah, I can keep going down the rabbit-hole of links as good as the next person. But that doesn't mean I don't ever restart my machine (on purpose, or, thanks to unstable code). When Safari gained the ability to "Reopen all Windows from Last Session," I was extremely pleased. Let's face it: Safari can sometimes die unexpectedly.

Syndicate content