Implementing BusKill: shutting down a Debian 11 Bullseye machine when a specific USB device is removed

Photo of assembled BusKill hardware, on a light wooden desk

I saw the BusKill security project some time back, and thought “what a neat idea”.

In essence:

BusKill is a Dead Man Switch triggered when a magnetic breakaway is tripped, severing a USB connection.

This blogpost is about my implementation of it, to shut down a laptop running Debian 11 Bullseye when a specific USB device is removed.

Why have I bothered

This is one of those things that I hope I will never need.

In fact, given that I hardly ever travel at the moment, and the likelihood of someone raiding the house and grabbing my laptop before I’ve been able to hit the “Power off” button seems very low.

Still, I thought that this was a cool concept, and I was keen to give it a try.

Will I use it in practice? I don’t know. Perhaps, if I travel more again.

Do I expect to be mugged for my laptop, or have some hostile nation seize it while I’m working on a train? I very much doubt it. I am very dull.

You need some hardware

You need some common, very easy to find, and not overly expensive, hardware to make this work:

Photo of the constituent parts of the BusKill hardware, lying unassembled on a desk

The BusKill docs have some suggestions.

If you do not want to buy the bits for your own setup, BusKill also retails a pre-prepared kit.

I bought the bits from Amazon, and they came to £35. I went for a USB-C solution, because it is easier to find a breakaway magnetic USB-C adapter than a USB-A one.

Setting up the hardware


The USB flash drive

I am writing this bit because it took me a while to realise that I wasn’t missing something. I’ve also put a pull request in to update the official docs.

You do not need to install anything on the USB device. You don’t need any special software on there, or any config file.

The USB device is just a way of creating something which can be physically removed from the system, giving an event which can be leveraged to trigger commands.

(You could store something on the device, I guess, but just remember that, when you remove it, you’re going to trigger whatever event you’ve configured your system to run. So probably easiest to leave it blank.)

Creating the software trigger

There are (at least) two ways of creating the software trigger, which detects the removal of the USB device and does something.

The easy way is to use the BusKill software client.

The harder way - but the more flexible way - is to use a udev rule.

The BusKill software

The BusKill project has released a GUI application, available for multiple platforms, which makes it very simple indeed.

You download the relevant version of software for your OS, and run it.

By default, it is disarmed, so you click a button to arm it.

Then, when you remove a USB device - right now, that’s any USB device - it locks your screen.

It’s fantastic that there is such a simple, user-friendly, approach. Making this kind of tool accessible is hugely valuable.

For me, it was not going to be an ideal solution, because:

If you like a GUI solution, and you are content with its current limitations, this is available, and that is an excellent thing.

But I wanted something a little different, so I reached for udev.

Triggering BusKill via a udev rule

For me, tying the device in with udev has a couple of advantages:

Rule specification

I wanted a rule:

Identifying my specific USB device

Since I want the rule to trigger only when I remove a specific USB device, rather than all USB devices, I needed a way to identify that specific USB device.

To do this, I used:

sudo udevadm monitor --kernel --property --subsystem-match=usb

I plugged in the USB device, and removed it, and looked through the output.

The most obvious variable was PRODUCT. I tried a few USB devices, and this variable changed with each one, so, while I can’t promise it is unique, it is probably good enough for my needs.

With that identifier, I could craft the udev rule

My udev rule

I created a new file at:


and added my rule:

ACTION=="remove", SUBSYSTEM=="usb", ENV{PRODUCT}=="000/11z1/999", RUN+="/usr/sbin/poweroff"

“000/11z1/999” was the value of PRODUCT I extracted using the previous step.

Note that just using poweroff does not work, because whatever executes the udev rule does not know where to find the poweroff command. So use the full path.

(You could add whatever you want here. Perhaps a ping to a specific server, to inform others that your BusKill trigger has been pulled. Or even send an email. But, if the intention is to stop an attacker from gaining access to the files on your device, be careful not to implement additional complexity which slows that down or, worse, causes the shut down to hang.)

I then reloaded the rules:

sudo udevadm control --reload

I tested removing the device, and the computer immediately shut down.

How to use it

It’s very easy to use.

And that’s it.

Don’t forget to either disarm the software before removing your device, or shut down your computer first. Especially if the trigger does something destructive. I guess you’ll only make that mistake once.

There are three reasons why I’m not proposing to use a LUKS-killer, or anything that will wipe or make my data inaccessible:

Donating to the BusKill project

Although I build the device using bits I sourced myself, and although I’m not using the BusKill GUI, I felt it was important to support the project. After all, without the project, I would not have thought of doing this.

So I made a donation.