** (nm-applet:2211): WARNING **: <WARN>  request_name(): Could not acquire the NetworkManagerUserSettings service.

Error: (9) Connection “:1.18″ is not allowed to own the service “org.freedesktop.NetworkManagerUserSettings” due to security policies in the configuration file

The fix was to edit /etc/dbus-1/system.d/nm-applet.conf and copy some of the permissions given to the root user over to the default context.

By the way, this requires ck-launch-session to be running. FYI, here is what my ~/.xinitrc does:

xmodmap ~/.Xmodmap

batterymon &

ck-launch-session &

nm-applet &

volumeicon &

awesome

Goal: Create an ArchLinux guest image that can be booted in qemu-kvm using a custom kernel specified to qemu-kvm with the -kernel option, and which doesn’t use an initrd. (Such a host can be used for testing kernel work.)

Part 1: Installing the guest. This wasn’t too bad; there are instructions out there. The problem I ran into was trying to do it without using a GUI, since I was actually doing the install on a remote machine I was connected to using SSH. Maybe there’s a way to get around the problem I had using X forwarding and/or VNC, but I used the –curses option on the qemu installation command line. (I tried the same thing with a Debian image and could not get it to work, though.)

Part 2: Compiling the kernel. In the “normal” boot process, the kernel starts; passes control to an initrd, which loads the filesystem drivers and then passes control back to the kernel; and /sbin/init is started, which sets everything up for the OS and spawns a login shell. We want to skip having an initrd. So, we need to compile our filesystem drivers directly into the kernel (i.e. not as modules). I used ext4 when I installed Arch Linux, so I had to add that to my kernel config. Everything else I needed was already in my config. I had a config designed to work with x86-64 qemu-kvm “hardware,” which I got from a colleague. Without that, the process of getting a working kernel config may have been much worse.

Part 3: Booting the guest. I used a command like the following:

qemu-system-x86_64 -smp $NR_CPU -cpu core2duo -hda $IMAGE -m 2000 -net nic,model=e1000 -net user -k en-us -kernel $VMLINUZ -append "console=ttyS0 root=/dev/hda3" ro -nographic -redir tcp:3333::22

First, note the root=/dev/hda3. For some reason, my root partition always becomes /dev/hda3 instead of /dev/hda1. You may have to play around with this. It’s OK to guess different numbers until you get it to work.

The -nographic is what lets this work over an SSH terminal; the console=ttyS0 tells the kernel to send output to serial console 0, which is what qemu interfaces with in -nographic mode. If you run this command without modifying the guest OS at all (just doing a basic install), the guest will appear to hang right when a login: prompt should be presented. It turns out, that’s because init has to be told to present an instance of agetty on ttyS0 (normally it’s not presented there). (NOTE: the following instructions may be slightly off for other distros.) To make this happen, you need to modify /etc/inittab in the guest (should be fairly obvious how to do so). You will now get a login prompt, but you will not be able to log in as root. To allow root to login from ttyS0, you need to modify /etc/securetty in the guest (again, pretty self-explanatory once you look at that file).

By the way, the -redir tcp makes the host port 3333 tunnel to the guest port 22, so if you run an SSH server on the guest at port 22, you will be able to connect to it from the host if you ssh to localhost port 3333.

Additional tweaks: I found that my Arch Linux guest was not sending printk messages to the console (as I wanted), or at least, not the ones I was looking for. You can configure what “level” of printk message get sent to the console by writing to /proc/sys/kernel/printk or by putting kernel.printk = <# # # #> in /etc/sysctrl.conf. I got it right by using 7 4 1 7.

Special thanks: #archlinux IRC channel, and particularly the user falconindy, who gave good advice and kept a good sense of humor despite my obvious frustration.

Since the government-forced takeover of Wells Fargo by Wachovia, I’ve noticed a marked decline in service when engaging with the Wells Fargo side of the company, but have still had excellent service when engaging with the Wachovia side.

These lines were added to the end of my “Keybindings” table.

Except that it always made me re-enter the network password. This was despite following all instructions on Arch Wiki.

A number of people on the Internet apparently have had related issues. (Many people complain about gnome-keyring issues, but I haven’t had that problem, possibly since I don’t have GNOME). In the past, I found some “potential” fixes that involved massive updates to obscure configuration files (i.e., copy these 100 lines into /etc/somedir/somefile, this works for me but you may need to modify for your system). I didn’t try these.

Finally, today. I found out that you can do sudo nm-connection-editor and set up your networks in there, then check the “Allow all users to access this network” box. Bingo! This worked for me, though your mileage may vary.

P.S. I’ve disabled blog comments because I had started getting like 20 spam comments a day. Hopefully I’ll find a solution soon.

I wanted to encrypt my netbook (running Arch Linux). Using the Arch Linux wiki as my primary source, I didn’t find the process to be too straightforward. In particular, the LUKS article seems to assume you’re doing a fresh install, which isn’t necessary. I hope to make the process easier for others and clarify my own thinking about it.

Who is this article meant for, and how do I read it?

This is meant for someone who doesn’t know how to do encryption on their computer (ideally an Arch Linux system, although I think it’s pretty Linux generic). It’s intended to be read linearly. I’d welcome any feedback/suggestions/clarifications/amendments, etc. There’s a lot of really cool stuff you can do that’s not mentioned here.The wiki links below are excellent sources of information.

Why encrypt?

There are a number of reasons why you might want to encrypt your data. In thinking about what kind of security I need, my imaginary “adversary” is an airport agent who can seize my laptop, copy the data off it, and pass the data on to a buddy who specializes in identity theft or stealing credit card numbers. Since I plan on international travel, and since I have this kind of information on my netbook, this is an actual concern for me.

What are the options for encryption?

1. GnuPG. Good for emails and possibly if you want to encrypt a few files. Not what we’re looking for here (I want to encrypt at least my entire home directory).
2. TrueCrypt. Can be used for full partition encryption or for creating an encrypted file or directory. This would be an acceptable tool for the job. However, I was told in IRC that TrueCrypt is “easier but not as professional.” In my experience with it, it can be kind of opaque, and the authors’ website is really sketch. So those marginal factors are what let me to go with option 3. Note that TrueCrypt can give you plausible deniability (see section below), which isn’t something I’m interested in at the moment.
3. LUKS for dm-crypt. This seems to be the “professional” way to do it, and seemed to be “acceptably” well-documented. This is what I settled on. I’ve been really happy with this so far. I imagine you can get plausible deniability with it somehow, but I haven’t looked into it.

What is this “plausible deniability” issue?

What if somebody points a gun at you and tells you to decrypt your data for them? Or what if you just want to not look suspicious? Or what if you’re leaving/entering a country that does not allow you to take/bring in encryption, and you’re worried they’ll actually catch you and enforce the rules? You woul want to hide the encrypted data by making sure it looks like random data, and then making sure the rest of your data looks legit and “normal.” You could even have a secret encrypted partition inside an “obvious” encrypted partition. This isn’t really a concern of mine right now, and so is outside the scope of this article.

What needs to be encrypted?

Ideally, you keep all your private data in your home directory. So you don’t need to encrypt the root partition. Some people do, but I personally would like to avoid that. You also don’t want to encrypt your boot partition, unless you want to make your computer only bootable from an external USB drive. That’s a pain, and probably not worth it unless you really want to (mostly) defend against the Evil Made Attack, which I’ve written about before. I’m not that paranoid. Additionally, there is concern about /tmp. If you set up /tmp to be a separate partition from / and to use tmpfs, the data is lost whenever you reboot, so there’s no concern. I actually don’t have this setup, but I’m not worried that any programs I use will write sensitive data to /tmp. So that issue isn’t further covered in this article.

What do you need to encrypt? /home, and the swap partition. The swap partition stores data that won’t fit in main memory, if all your memory gets used up. So if you don’t encrypt it, open file in /home could leak into swap space and onto your hard drive. A determined attacker (e.g. computer-savvy criminal) would be able to retrieve it with a tool like Foremost.

How do I figure out how my partitions are set up?

You can do this by catting /etc/fstab. Typically, partitions are given names like /dev/(s|h)daX (where X is an integer) by the Linux kernel. Under normal conditions, they don’t change numbering. However, there are some circumstances in which they may. Arch Linux by default now uses UUIDs for each disk in the /etc/fstab. If you want to correlate these UUIDs to the normal partition names, run the command blkid as root.

Under Arch Linux, /home is on its own partition by default, so I’m going to assume you have that setup already.

Do I need to back up?

YES. In my case, I’d been using my netbook for a while, so I just backed up my home directory, and then after I had an empty encrypted home partition, I copied it back over from an external USB drive.

How do I clear out any old, possibly sensitive data that has been written to /home or swap?

dd if=/dev/zero of=/dev/sdaX, replacing X with the appropriate partition. For me, /dev/sda2 is swap and /dev/sda4 is /home. This wries zeroes over the entire partition, destroying it. There are other options (e.g. /dev/urandom to write random bits), and they are documented in other places (not here).

What software do I need to install?

With Arch Linux, at least in my case, I already had everything I need. The cryptsetup package is part of the ‘base’ Arch Linux package group. I don’t know where the dm-crypt and aes-i586 modules come from (NOTE: plase let me know if you can tell me how to find out this information…). If it turns out you don’t have something, you can probably get it pretty easily with your package manager.

OK, how do I set it up, already?

Load the necessary modules (I’m assuming aes encrpytion):

# modprobe dm-crypt
# modprobe aes-i586

Write a LUKS (Linux Unified Key System) header to your /home partition. You’ll be prompted for a passphrase, which you will have to supply in order to use the encrypted partition in the future. It’s also possible to use a keyfile, but that’s not covered in this article.

# cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sdaX

Mount the partition. This will create a device at /dev/mapper/home which is what you actually read to/write from (i.e. it performs the encryption and decryption). You’ll be prompted for your passphrase.

# cryptsetup luksOpen /dev/sdaX home

Create an ext4 filesystem (or some other filesystem of your choice) in the partition.

# mkfs.ext4 /dev/mapper/home

Update /etc/crypttab, which will be checked automatically at boot time. The following entry should work for you. It tells dm_crypt to ask for a passphrase to mount /dev/sdaX as /dev/mapper/home, and to create a new swap partition at /dev/sdaY with a random key.

home /dev/sdaX ASK
swap /dev/sdaY SWAP -c aes-xts-plain -h whirlpool -s 512

Update your fstab to reflect the /dev/mapper devices, instead of /dev/sdaX (or possibly UUID=) devices.

/dev/mapper/swap swap swap defaults 0 0
/dev/mapper/home /home ext4 defaults 0 1

What else do I need to do?

You need to add dm_crypt and aes_i586 to the MODULES list in /etc/rc.conf.

That’s it. When you boot up, you should be asked for your passphrase.

Are there any pitfalls?

The only problem I had was that I originally set up my swap partition to be a LUKS encrypted partition with a passphrase. dm_crypt will not create a swap device for a partition that already has a LUKS header, so I had to re-zero the swap partition.

What if I need to change my passphrase?

This might happen if you accidentally reveal your passphrase. Fortunately, it’s not a problem.

You can have multiple passphrases for each encrypted partition.

To add a new passphrase, do this:

# cryptsetup luksAddKey /dev/sdaX

To remove an existing passphrase, do this:

# cryptsetup luksRemoveKey /dev/sdaX

In either case, user-friendly prompts will guide you through the process.

Special thanks

Contributors to the Arch Linux wiki (which is pretty much where I figured all this stuff out, although there were some non-obvious stumbling blocks for me), and the #archlinux IRC channel, which proved helpful.

Is this article a work in progress?

I’m sure it could use some more editing, and may receive some, but I think it’s reasonably complete, in that I don’t believe I’ve left out anything important and non-obvious.

My motivation is that for some reason the Arch Linux article on VirtualBox was not very clear on this point (perhaps very outdated?). I don’t want to update it myself–would rather allow an expert to do so–but I do want to record/make available the method that worked for me.

First, make sure Guest Additions is installed in the guest OS.

Second, execute something like the following in the host OS:

VBoxManage sharedfolder add WinXP --name shr --hostpath /home/mollison/shr

In the above, WinXP is the name of the guest, shr is what I’m calling the shared directory, and /home/mollison/shr is its location on the disk.

Third, boot up the guest and execute the following in a terminal:

net use x: \\VBOXSVR\shr

Now, in My Computer, the share folder is accessible as the X drive.

I believe there are other ways to do this that allow for faster file transfer, but this is easy and quick to set up.

The trick was to (a) tell CUPS that the printer had a duplexer installed (which was not the default assumption); and (b) tell my application that I wanted to do dual-sided printing (which was not the default assumption). I had tried (b) before, but never noticed (a).

Also, updating to a slightly more modern CUPS and telling it the printer was slightly older may have helped.

Isn’t it ironic that this is [Exploit the] Earth Day?

Well, for once, I am going to say something positive about something I’ve previously complained about.

Although it was really hard for me to get an appointment at Campus Health Services, because they do not actually answer their phones for the entire time span they claim they do, when I finally did get an appointment, everything went really well. I’ve been twice recently and practically everybody has been very helpful and caring, including medical and non-medical personnel. I’ve been so satisfied that I’m not going to bother to get an off-campus doctor (at least for now), which is something I was planning on doing.