Minion: Secure Wireless Boot Floppy

There doesn't seem to be a boot system out there that meets all my needs, so I built one. I call it Minion to evoke armies of disposable machines enslaved to my whim.

Let's break it down:

Secure:
Minion boots securely over the Internet. Physically secure hardware that normally runs questionable operating systems can be rebooted with confidence into my OS of choice. Open wireless networks are no longer a security problem.
Wireless:
It is often inconvenient to find or run a wire. Wired networks are also supported, but that's easy.
Boot:
Minion provides boot media that do nothing but boot a trusted OS over the Internet. These boot media never have to be changed, modulo bugs, even when the real OS is upgraded.
Floppy:
I have a few old PCs that don't have viable removable boot media other than floppy drives. Some have as little as 12MB memory, so space is at a premium.

These are the tools I use:

GPG authenticates the real OS via public-key cryptography.
This insulates the boot media from changes to the real OS.
Linux (-mm) kexec reboots into the real OS.
I couldn't find any similar functionality in any BSD or other OS, and this is absolutely required to avoid updating the boot media every time you upgrade your real OS. A real OS won't fit on a floppy anyway.
BusyBox is perfect for boot floppies
and other embedded applications. It includes everything needed to reboot from a network server, including udhcpc, wget, and md5sum.
Device drivers
support network hardware of interest, including adm8211, at76c503a, madwifi, and many wired and wireless drivers in the kernel tree.
Embedded filesystems
minimize space usage on the floppy (compressed romfs) and minimize memory usage (cramfs).
OpenVPN
secures UDP for the real OS, which I need for NFS. Native IPsec would be an even better choice, because it would occupy less memory at runtime, but I'm too dumb to configure it.
NFS
provides read-only access to the master system's binaries, libraries, and manuals. Unfortunately, SFS doesn't allow SUID binaries, so I need NFS. SFS also has a large memory footprint, so paging the SFS software over read-only NFS is a win.
SFS
cryptographically authenticates access to home directories. Too bad it refuses to do SUID.

Put all these together, and you have a well featured, flexible thin client platform. I'm still working on it, though.

Applications

I'm mainly interested in three kinds of minions:

Terminals:
The numerical majority of minions will be terminals used with SSH, VNC, or RDP to connect to other machines. Some of these are old machines inside my house, others are random and mobile machines connecting over the Internet, from hotels, friends' and relatives' homes, etc. Depending on what resources these machines have, they may be customized on the server to make use of CPU horsepower, disk storage, peripherals, etc., temporarily.
Appliances:
Various machines in my house, and maybe in other locations in the future, are connected to known resources. TVs, video capture cards, CD and DVD drives, printers, scanners, etc. I want to be able to hook these up to my network without trusting the minions. I'll use the minions connected to wireless access points to extend my home wireless network by connecting its many open WLANs together.
Servers:
Some minions will be physically secure and trusted, such as CPU servers and, to some extent, disk servers. These are essentially network-connected peripherals.

I certainly don't mean to imply that these are special cases. I just mean to indicate how I plan to apply Minion.

What Minion Is Not

It's useful to say what Minion doesn't do, rather than omit it:

Minion nodes are not autonomous.
They are minions. They don't try to survive server failures, or work across master reboots, or anything like that.
I'm not trying to support low-bandwidth connections.
Isolated networks need their own Minion servers to serve clients on those networks. Minion/PPP wouldn't work.
Minion doesn't try to be a gateway.
We only try to work on maintained networks, with DHCP servers and gateways. We don't try to speak PPPoE or whatnot to connect to the Internet.

Not that I wouldn't want to do these things, but I don't need them right now.

-- Peter Szilagyi <szilagyi@alum.mit.edu>