21 April 2014 § Leave a Comment
In the previous post, I described some of the barriers to using FileVault 2 to protect data on a laptop hard drive. I have since made some discoveries that shine a light in what looks like a pretty dark corner of OS X. In the previous post I conclude that FileVault 2 offers no protection against data snoops because OS X unlocks the disk when an administrator logs in. The security afforded by an administrator account can be circumvented in a matter of minutes. Under 10.7, a user could not access the system login screen until entering in the disk password. It appears that Mavericks can be made to work this way. The older behavior occurs if the disk is encrypted using the “encrypt” item from the contextual menu that appears when ctrl- or right-clicking on the disk icon on the desktop. The insecure behavior occurs if the disk is encrypted using the FileVault 2 system preferences pane. I take it that the password is required to access the disk even if the machine is booted from an external disk. The machine cannot be booted into single user mode until the disk access password is entered, which defeats one of the ways most likely to be used to take control from an administrator.
I conclude that the combination of a good disk access password and a good administrator password offer effective data security against data snoops, unless they have access to a quantum computer.
I wonder if storing sensitive files on an encrypted disk image would provide still increased security, beyond what is afforded by requiring the user to enter an additional password.
11 April 2014 § Leave a Comment
If Mavericks’s implementation of Filevault 2 has any use, I can’t see it. Before I had installed Mavericks, I had used FileVault 2 to encrypt my laptp’s hard drive, and I recently decided to start using it again. I chose a suitably long and obscure password that I could easily remember and enter and pushed “encrypt.” Great, right? Feeling a little safer, I happily coded away (with a good bit of web surfing, to be sure).
Leaving the back doors unlocked, on purpose
On the next restart, the password entry screen for FileVault 2 didn’t appear. Formerly, a blue-grey screen would appear with a text entry field, which could only be bypassed with the FileVault 2 password. I checked everywhere I could think of for an option to require the Filevault 2 password on boot. I’ll save everyone the trouble of looking. Mavericks prevents this. I haven’t been able to find a way to change this behavior. This renders FileVault 2 of little use. There are well-known ways of resetting or by bypassing passwords for administrator users; since Mavericks allows administrators to bypass the FileVault 2 password field, this means that it provides no real protection. I can’t think of a scenario in which FileVault 2 can provide any meaningful protection for any disk that can be booted. I haven’t experimented yet with a disk used purely for data storage. Based on my recollection of the old FileVault 2, I would expect that the disk wouldn’t mount without the FileVault 2 password. I am pretty sure even a root user cannot mount a FileVault-2-encrypted disk without the password.
Defeating the exploits
There is a way to defeat one of the exploits that allows bypassing the login screen. Booting in single user mode gives immediate access to terminal prompt—as root. I can’t think of a more foolish idea. This is unfathomable. Clearly this open back door is intended as a mechanism for IT support, the Genius Bar, for instance, to perform heroic recovery efforts in case a user has forgotten his or her passowrd or damaged the OS so that it can’t get past even the earliest stages of the boot procedure. To defeat this, the boot procedure can be configured to require a password for root access. This isn’t especially difficult, or, if done conscientiously, risky.
Defeating the other exploit, which uses Apple utilities to reset administrator users’ passwords or bypass them entirely, requires extreme measures: so far as I can tell, it requires that a hardware-level PRAM password be set. Mistakes setting the hardware-level password can be fatal, requiring the machine to be sent back to Apple. Forgetting the password will have similar consequences.
If you want to scare yourself silly, you can read about these exploits, which are well-documented.
Conclusions about FileVault 2
I conclude that FileVault 2 encryption only makes sense for a boot disk in Mavericks if the PRAM password is set and the boot process is configured so that root access requires a password. The root-access password is needed in case someone who knows the PRAM password attempts to start the machine in single-user mode.
How good is it?
If these measures are taken, what level of security is acheived? The disk will be safe from people like students who want to access their grades on a professor’s laptop; thieves who lift the mac and want to access personal data before selling the machine; or someone who finds a misplaced laptop with patient data or other confidential documents.
from the moment the first quantum computer is turned on, all messages previously encoded with RSA will be readable. Any secrets that need to remain so after that moment, whether it comes in 10 years or next week, should not trust RSA now.
This permits access for university researchers, well-funded intelligence services such as everyone’s favorite, the NSA, and major multinational corporations. Quantum computing is expensive and requires rare expertise! If the US government wanted access to a machine protected in the manner I am suggesting, it would be simpler than using a quantum computer to compel Apple to access the PRAM password. I doubt that this is illegal under laws like the USA Patriot Act. No doubt the user him- or herself would be interrogated—low tech and probably effective!
The picture is a little rosier if the would-be snoops do not have access to quantum computing. Even top-grade decryption algorithms running on a cluster would probably still take a days or weeks to crack a good password. If the disk is removed and accessed on a machine booted from a different disk, if FileVault 2 behaves as it did in its pre-Mavericks state , the Filevault 2 password is needed.
What’s the use of a password anyhow?
The reason to use a password is to restrict access to the email account, system user, confidential information, etc. Making it available to people that can’t be trusted defeats this purpose entirely. Almost every password-accessible user account online has a “forgot password” utility which provides the user and the user alone with the ability to reset his or her password. Even the system administrator is not permitted access.
Don’t forget the password. Write it down and put it in a safety deposit box. Make it memorable. Don’t share it. Otherwise, don’t bother using one in the first place. And by all means, and now I am talking to you, Apple, don’t make an OS that renders passwords useless!
9 April 2014 § Leave a Comment
I struggled for more hours than I would like to say trying to compile Gerd Neugebauer’s BibTool utility on my mac (OS 10.9.2). I kept running into problems with the kpathsea libraries. Not surprisingly, an old thread on the Mac OS-TeX mailing list provided the necessary insight. I’m reposting it here so that it might get better exposure on the Internet for those trying to do the same thing. Of course, someone who wasn’t shamelessly hacking away at it probably wouldn’t have had any problem at all . . .
BibTool is an amazing utility that does all those things we all wished BibDesk would do, but doesn’t: command line tools for removing fields, rewriting fields, grabbing references based on various criteria including regular expressions, pretty printing.
On Nov 23, 2009, at 1:49 PM, Jan Erik Moström wrote:
> I’m a bit slow (in all kind of ways and I’m just trying to figure out the MacTeX distribution … one thing that that I would like to do is to install “bibtool” (not bibtools) but I can’t figure out how to do this in a simple way. Using Gerbens TeX distribution it was possible to use the i-installer but now I’m at a loss how to do it.
You can download the source and compile it yourself from http://www.ctan.org/tex-archive/biblio/bibtex/utils/bibtool/
(Get the *.gz) file.
Once you have expanded the tar archive, copy the makefile.unx file to makefile, then run
sudo make install
sudo make install.man
This will place a working copy and manual pages in the /usr/local tree.
As long as you have /usr/local/bin in your path, things should work.
Of course, you have to have the developer tools to do this.
There are many options to set specific details during the compilation process, but I just did a vanilla “make” and
gave me the typical “usage” statement.
I’ve never used bibtool, don’t know how to use it, and don’t have any test files to ensure that it works in a real-life situation.
Otherwise, I now have a seemingly-functional version of “bibtool” that runs on X86_64 Snow Leopard.
I don’t guess that really helps you, but if you want it, send me a message off-list.