Ubuntu uses an event-based system called udev that, among other things, can run a script when a USB device is plugged in or unplugged. Local (ie: user-created) udev rules are stored in /etc/udev/rules.d/. Before you can create a rule, you need to know a little about the device that is going to trigger it. Open a terminal and type:

udevadm monitor --udev --environment

Connect your USB device. It doesn’t have to be a USB key, it could be a phone, for example. A bunch of text will come up. Look for “ID_SERIAL” and “ID_VENDOR_ID”. Write down the values of those. You can use other variables if they suit your device better, just change the rules file accordingly.

Create a file called “/etc/udev/rules.d/85-screen-lock-toggle.rules”. Put the following in it, replacing VALUE with the proper value:

File: /etc/udev/rules.d/85-screen-lock-toggle.rules

ACTION=="remove", ENV{ID_SERIAL}=="VALUE", ENV{ID_VENDOR_ID}=="VALUE", RUN+="/usr/local/bin/gnome-lock-enable"
ACTION=="add", ENV{ID_SERIAL}=="VALUE", ENV{ID_VENDOR_ID}=="VALUE", RUN+="/usr/local/bin/gnome-lock-disable"

Next create the scripts to actually disable and enable locking:

File: /usr/local/bin/gnome-lock-enable

#!/bin/bash
 
user=`ps aux | grep gnome-screensaver | head -n 1 | awk '{print $1}'`
 
if [ -n $user ]; then
	GNOME_SCREENSAVER_PROC=`ps xa | grep gnome-screensaver | head -n 1 | awk '{print $1}'`
	export `grep -z DBUS_SESSION_BUS_ADDRESS /proc/$GNOME_SCREENSAVER_PROC/environ`
	su $user -c "gconftool-2 --set "/apps/gnome-screensaver/lock_enabled" --type bool 1"
fi

File: /usr/local/bin/gnome-lock-disable

#!/bin/bash
 
user=`ps aux | grep gnome-screensaver | head -n 1 | awk '{print $1}'`
 
if [ -n $user ]; then
	GNOME_SCREENSAVER_PROC=`ps xa | grep gnome-screensaver | head -n 1 | awk '{print $1}'`
	export `grep -z DBUS_SESSION_BUS_ADDRESS /proc/$GNOME_SCREENSAVER_PROC/environ`
	su $user -c "gconftool-2 --set "/apps/gnome-screensaver/lock_enabled" --type bool 0"
fi

Make the scripts executable:

sudo chmod a+x /usr/local/bin/gnome-lock-enable /usr/local/bin/gnome-lock-disable

Restart udev:

sudo restart udev

Enjoy the convenience.

The cool thing about the Yubikey is that it shows up as a keyboard. It will work on any computer without the need to install drivers. But the keyboard driver is limited in its ability to receive data from the computer. There is, however, another widely available driver that does support two-way transfer: the Mass Storage Device.

Let’s say a company designs a USB flash drive that shows up on the computer with a number of folders: ‘sign’, ‘encrypt’, ‘output’, for example. Copy a file into the ‘sign’ folder, press a button on the drive, and a signed copy is placed in the ‘output’ folder. Now you have the ability to sign, encrypt, decrypt data on any computer. Encryption would require it to somehow manage public keys. Perhaps you could copy a file and a number (1+) of public keys to the ‘encrypt’ folder.

To use it as an authentication token:

1. A website provides you with a random string: “12345″
2. Copy it to a text file in the ‘sign’ folder
   • To avoid replay attacks the URL should be appended or something
3. Press the button
4. Copy the contents of the signed result into a textarea (or upload it)

Of course, this could all be done automatically by an extension or the browser itself.

The important feature of this is it could be implemented now. It would not require the propagation of a new generic driver. The USB Mass Storage driver is available all the way back to Windows 98, default since XP, default since OS9, available in Linux since 2001. It is nearly as omnipresent as the keyboard driver. It also doesn’t make any assumptions about the algorithm used. There could exist PGP, S/MIME, symmetric key versions.

This is just a general sketch. I recognize some security concerns (malicious software could piggyback on the signing process to generate signed files). A more secure one might allow only one file to be written to the drive at a time, requiring user interaction to unlock it each time.

It seems to me that they are missing the problem. The problem is the way DNS servers handle in-bailiwick additional records. If I request an NXDOMAIN from an ISP, I can be reasonable assured that a request will be made by the ISP to Google’s nameservers (which are probably already cached). I can then spam the ISP DNS server with fake replies hoping I stumble on the right combination of port and transaction ID. My replies will include a record for my NXDOMAIN and also an additional record giving new IP address for Google’s nameservers. From then on, the ISP will turn to my provided IP rather than Google. Eventually I can provide it with fake records for www.google.com and other useful subdomains.

My question: why should the ISP overwrite the information it has already cached? Additional records should be ignored unless they are needed for the current query (as in the case of glue).

I know this doesn’t prevent DNS spoofing, but it does significantly lower the value of the attack. You may be able to plant a record for as7230hf.google.com, but you won’t be able to overwrite their nameservers.

Maybe I’m missing something. Maybe there really is a critical reason to allow a nameserver to tell you that it isn’t where it is. But I don’t think so.