Toggle Gnome screensaver lock on USB key insertion

Sunday, Sep 25, 2011 9:39 am
William Barnes

While I like my computer to lock itself automatically when I leave, it gets annoying when it does it every time I get up for a few minutes. I decided that it would be nice if I could toggle the screen lock only when I’m out of the apartment. I decided that the trigger should be the USB key I have on my keychain. It’s always with me. If it’s plugged in to the computer, then I’m likely home. I apologize for the (lack of) formatting of the code, I will be fixing that when I get my computer back up and running.

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:

  1. ACTION=="remove", ENV{ID_SERIAL}=="VALUE", ENV{ID_VENDOR_ID}=="VALUE", RUN+="/usr/local/bin/gnome-lock-enable"
  2. 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:

  1. #!/bin/bash
  2.  
  3. user=`ps aux | grep gnome-screensaver | head -n 1 | awk '{print $1}'`
  4.  
  5. if [ -n $user ]; then
  6. GNOME_SCREENSAVER_PROC=`ps xa | grep gnome-screensaver | head -n 1 | awk '{print $1}'`
  7. export `grep -z DBUS_SESSION_BUS_ADDRESS /proc/$GNOME_SCREENSAVER_PROC/environ`
  8. su $user -c "gconftool-2 --set "/apps/gnome-screensaver/lock_enabled" --type bool 1"
  9. fi
  1. #!/bin/bash
  2.  
  3. user=`ps aux | grep gnome-screensaver | head -n 1 | awk '{print $1}'`
  4.  
  5. if [ -n $user ]; then
  6. GNOME_SCREENSAVER_PROC=`ps xa | grep gnome-screensaver | head -n 1 | awk '{print $1}'`
  7. export `grep -z DBUS_SESSION_BUS_ADDRESS /proc/$GNOME_SCREENSAVER_PROC/environ`
  8. su $user -c "gconftool-2 --set "/apps/gnome-screensaver/lock_enabled" --type bool 0"
  9. 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.

Encryption in your pocket

Tuesday, Feb 24, 2009 8:21 pm
William Barnes

There was a recent discussion on Security Now about how nice it would be to have a Yubikey-like device that uses public key encryption to sign a provided string of text and thereby provide strong authentication without the need to share a secret key. Steve stated two problems: hardware limitations and driver problems. I don’t have a solution to the first problem, it’s up to somebody else to come up with a cheap USB device that can do public key encryption, but I think I have an idea for the second.

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.

DNS Spoofing

Saturday, Aug 16, 2008 8:29 pm
William Barnes

I have been thinking about the big deal in security at the moment: DNS spoofing. Everybody, it seems, is all caught up in trying to figure out how to add more bits. They want to make DNS replies harder to spoof.

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.