August 2006 Archives

I've done some updates to my LDAP Authentication in Debian Sarge HOWTO. I added a note about how allowing LDAP clients' root users to have administrative access to the LDAP directory by putting the admin password in a root-only readable file may not be so secure. This method makes it really easy for utilities to do LDAP administration when run by the root user, but writing important passwords to disk in the clear is yucky, even if the file is only readable by root. Perhaps some day I'll write more about alternative strategies like using slapd's ACLs to allow users in certain groups to modify any entry, thus making it so administrative users can just use their normal LDAP password to authenticate when they need to do administrator things.

The other update is a note about a race condition in the add user and group scripts I wrote and link to in the HOWTO. If more than one instance of one of these scripts is running at once, it's very possible to create two users or groups with the same numeric ID. I don't have any plans to fix these scripts, so if you use 'em, make sure only one instance of each is running at once against any given LDAP directory! I'm working on a (hopefully) really cool LDAP administration tool at work that will more intelligently check for available UIDs/GIDs, and will post here when that's released.

I was really happy when Apple added the "Secure Virtual Memory" option to the Security pane System Preferences (I think this was with the release of Tiger). I'm a big fan of encrypting swap files/partitions. Encrypting sensitive files on disk is great and all, but it doesn't do you much good if the data in those files sits in memory that gets swapped out to disk in the clear. If someone steals your hard drive, she can find all kinds of handy info in your swap files. So, I use Secure Virtual Memory to encrypt those swap files on my Macs. I've also used dm-crypt to do it easily in Linux, I believe GBDE can do it in FreeBSD, and OpenBSD I'm fairly sure just encrypts swap by default. I don't know what you do in Windows; in the past I've just turned off the page file, or whatever Windows calls it, completely.

Anyway, I discovered today that recent Apple laptops can do what Apple calls "Safe Sleep." This is known in the Linux world as suspend to disk, or hibernating for Windows folks. During Safe Sleep, the contents of your computer's memory are written to /var/vm/sleepimage, so your computer can completely power down, and still be able to boot quickly to the state you previously had it in when you open it up again (in normal sleeping, most of the computer is powered down but memory is kept on to preserve its contents). It seems that any time you put your Safe Sleep enabled Mac to (normal) sleep, memory gets dumped to this file so it can later go into Safe Sleep mode if the battery is removed or runs out.

Kind of cool, but not a feature I want. Safe Sleep, like I imagine other suspend-to-disk systems, just writes all your memory to disk in the clear. This is even worse than cleartext swap files, because it's all of your memory. Try running strings on /var/vm/sleepimage, or maybe grepping for passwords from it. According to where I was reading about Safe Sleep (here), there is an option to encrypt the memory when it is dumped into /var/vm/sleepimage, but this option might not work (it didn't at the time that article was written). I didn't test it myself. I just turned Safe Sleep off completely with this command:

sudo pmset -a hibernatemode 0

Then, you might want to blow away the sleepimage file created when you last put your mac to sleep as follows:

sudo rm -P /var/vm/sleepimage

The -P option to rm overwrites a file completely with ones, zeros, then ones again before unlinking it. Note that this will take a little while to run, especially if you have a lot of RAM (and thus a big sleepimage file). I haven't seen this option with the GNU rm typically used in Linux, but if you have Linux you probably have a GNU utility that comes with coreutils called shred, which can do the same thing (and by default will much more thoroughly overwrite files).

http://www.andrewescobar.com/archive/2005/11/11/how-to-safe-sleep-your-mac/ has a lot more useful info about Safe Sleep.

For some reason throughout all my years of using *nix I haven't ever paid attention to what Anacron is or what it does. I just figured it was something like regular old cron. But, I just learned some more about it and feel really silly for not knowing about it before now.

Anacron schedules the execution of various scripts or commands, like cron does, but it's more flexible about what time it actually runs the jobs. Cron runs things exactly at the time the crontab says to run them. If the computer is not up and running at that time, the cron jobs don't get run. If Anacron is run and it determines that a job that is supposed to run daily hasn't run in more than a day, it goes ahead and runs it right now, then updates a timestamp file to indicate that the job has been run for today. My main computers are generally sleeping (and hence cron is not running) when I'm not using them, so OS X's nightly cron jobs that run at 3:15 AM, for example, pretty much never get run. Anacron makes it so they do get run automatically when I wake the computer up in the morning. If you install Anacron using Darwinports, it even puts lines for running the daily, weekly, and monthly crons in /opt/local/etc/anacrontab, and all you have to do is uncomment those lines.

This is great. Now I can finally have backups of my home directory happen automatically every day I have my computer running, even when I keep it sleeping a good portion of the time. I'm thinking about writing a little backup script to run with Anacron that sends me notifications about the backups using Growl. If I do so, I think I will also try to make it work easily using D-Bus for the notifications if you're using Gnome or something.