Mac OS X 10.7 and earlier: Launch whatever app you want, the OS doesn’t care.
Mac OS X 10.7.5: Gatekeeper appears, but is a benign master, defaulting to allowing apps from anywhere. You can still install and run anything without any intervention from the OS.
Mac OS X 10.8 through 10.11: The benign master is slightly less benign, as the default setting changed (somewhere in that timeframe) to only allowing apps from the Mac App Store and registered developers. You could still disable Gatekeeper completely, though, as the “Anywhere” button was still present. If you didn’t do that and tried to launch an app from outside the store or a non-registered developer, you had to click OK in one dialog box. Still not awful, but you were aware you were working outside the Gatekeeper’s happy zone.
macOS Sierra (10.12): The benign master is now clearly just the master—the “Anywhere” button is gone. (Gatekeeper can still be disabled in Terminal, if you wish: sudo spctl --master-disable.)
And when you try to run an app from an unidentified developer, you really have to jump through some hoops…
Most cloud services tell you that their data stores are safe, that your data is encrypted in transit and on their drives, that employees don’t have access, etc. For the vast majority of the stuff I store in the cloud, this is more than good enough for me—the data isn’t overly sensitive, and if someone were to hack their way in, all they’d get are a bunch of work and personal writing files and some family photos.
For other files—primarily financial and family related—those assurances just aren’t enough for me. But I still want the flexibility and security that comes from having a copy of these files in the cloud. So what’s a paranoid user to do to take advantage of the cloud, with added security, but with a minimum of hassle?
The solution I came up with involves using local encrypted disk images and a shell script. Using this script (and some means of scheduling it), you can automatically encrypt and back up whatever files you like to a cloud service.
Note: This article has been heavily modified, as I was a total knucklehead and completely forgot about GPL v3—thanks to Geordie Korper for pointing it out in the comments. Basically, the cause of the aging Unix tools in OS X is GPL v3. I’ve updated the following table to include the license information. In every case but one (nano), GPL v3 is the license on the non-updated apps. So that’s that…I’ll leave this up, though, in case anyone’s curious about this stuff.
At some point, Apple will release an OS X update containing a patched version of bash. (Update released.)
So while Apple has patched bash, this version of the shell is simply ancient. Just how old is it? bash 3.2.53(1) is roughly seven years behind the current version, 4.3.25. Seven years is like, well, forever, in Internet time!
With that bash age gap in mind, I took at look at a number of common Unix apps—in both Mavericks and Yosemite—to see which versions were in use. Then I checked the same apps in MacPorts, a tool that makes it simple to install many Unix apps.
(MacPorts doesn’t necessarily have the absolute latest version of every Unix app, but they do stay relatively current. For instance, they already have a patched version of bash that fixes the above vulnerability.)
The results were interesting, to say the least—many of the core Unix utilities in OS X are years and multiple versions behind their open source, er, sources. You can thank GPL v3 for that, as noted above (and covered in more detail below). But that still leaves the big question:
Does it matter?
That is, should we care that these tools aren’t keeping up with their latest and (presumably) greatest versions? Is it a problem, or merely a statement that what we have works well enough for the majority of users? (For those who don’t want to bother reading, my general opinion is no, it doesn’t matter.)
The recently-released OS X 10.4.7 update included a not-announced Dashboard widget update feature which silently checks to make sure that your widgets are valid. I agreed with the need for such a feature, but wrote about how I think Apple could have implemented things a bit better.
I was frustrated after writing my Leap-A Q&A for Macworld yesterday, as I couldn’t get Oompa Loompa to do what it was supposed to do–it wasn’t infecting my files, and it wasn’t sending itself out over iChat. So today, my friend and coworker Kirk McElhearn and I spent the better part of the day testing Oompa Loompa on a couple of controlled Macs. We wanted to figure out exactly what it did, or did not, do, and what to do about it if you found it on your machine.
You can read the results of our efforts in the article titled Digging deeper into the Leap-A malware. It took quite a while, but we think we finally figured out exactly how it works (and doesn’t work), and offer some advice on removal. Among the more surprising findings was that it will not attempt to send itself out over Internet iChat, only Bonjour iChat. It also won’t affect applications that are system-owned, only those that have been installed by a user (and are therefore user-owned). Both of these are why I wasn’t seeing the behavior I expected to see yesterday. My test machine had only Apple’s stock Tiger applications on it, and Kirk and I were testing with an Internet iChat.
I am now officially very sick of Leap-A, having spent probably 18 hours on it over the last two days. The short summary is that it’s a bad piece of malware that could have been worse…but it’s far from the self-propagating internet-spreading virus/worm that’s been described on other sites. At the end of the day, it’s really just a good reminder to be very careful about what you download and install on your Mac.
[Note: The following isn’t a slam on Apple’s security policies, nor am I chiding them for fixing a security hole. I merely found the description of one particular hole and its related fix somewhat funny, so I thought I’d have a bit of fun with it. Read the following as nothing more than a poor attempt at humor after a long day spent writing about security issues…]
Given the relative seriousness of the Leap-A malware/trojan (I put together a pretty straightforward Q&A page for Macworld, too), I thought the following look at the lighter side of security was worth sharing today!
A malicious local user may trigger a system crash by invoking an undocumented system call. This update addresses the issue by removing the system call from the kernel.
Now don’t get me wrong, I think patching security holes is a Very Good Thing. However, in this case, I have to question both the danger of the hole as well as the quality of the related fix. Let’s look at the ‘hole’ and ‘fix’ in more detail. First, consider malicious, which derives from the word malice. According to Merriam-Webster, malice is the “intent to commit an unlawful act or cause harm without legal justification or excuse.” So whomever this person is, they’re not around to help you out.
Next, local user. This means the person is directly connected to your Mac. They may be seated directly in front of it, or perhaps they have connected remotely via ssh or telnet. Either way, they’ve successfully logged into your Mac. This means that they’re either someone you trust (you need better friends!) who has an account on your machine, or they’re a hacker who has figured out a valid username and password and used that info to log in. So now we have a malicious local user, with some level of access to your Mac.
So just what is this malicious local user going to do now? According to the security notice, they’re going to trigger a system crash. That’s right. They’ve gone through all this trouble to gain access to your machine, and now they’re going to invoke an undocumented system call and bring the machine down. (If they’re physically local, pulling the power cord would do the same thing, and probably cause more damage in the process.) Granted, a crash is never a good thing, but consider this malicious individual again. They’re here to cause harm. Probably as much harm as they possibly can. And given that they’re logged into your machine, they can probably cause a lot more harm than a simple reboot. File deletion, creating evil symbolic links, installing a keystroke logger, etc. There are a lot of things they could do that are much farther up the ’cause harm’ scale than a simple crash.
But nonetheless, we don’t need to worry about this particular security issue any longer. Why not? Because Apple fixed it! Yes indeed, they sure did. They fixed it by removing the system call from the kernel. “Hey Doc, my arm hurts!” ‘No problem, I’ll have that arm off of there in a jiffy!’ I’ll certainly sleep more soundly tonight, knowing that some malicious local user won’t be able to use an undocumented system call to crash my machine!
Security issues are important. They really are; I think today’s dialog about Leap-A was good for the Mac community. And I think closing security holes quickly and effectively is also a Very Good Thing, as I stated above. But still, I couldn’t resist having a bit of fun with the nature of this particular hole and the related fix.