Fri, 28 Jul 2006
AFS as a backup mechanism
Create a cell, say, backup.awesmoe.org. Use a separate database to translate bizare volume names into a particular backup set (say, ab.d92fgaf9a8as0 to backup of foo.bar.awesmoe.org on 23 July 2005 03:28 UTC). You can mount these volumes in a tree, say /afs/backup.awesmoe.org/bydate/2006/07/23/foo.bar.awesmoe.org-200607230328 or /afs/backup.awesmoe.org/byhost/foo.bar.awesmoe.org/2006/07/23/.... Set acls to use list so that machine admins can see files (prolly have to use hashed list names as well --- what is limit on pts list name length?) Can even acl off so that various people can see certain bits from machines.
Use rsync as backup mech, can do incrementals. Merge incrementals to create fulls.
To backup afs, vos dump volumes, suck back into the backup cell.
Posted at: 09:13 | category: /computers/backups | Link
Fri, 21 Jul 2006
Netbooting Idea
One issue with netbooting computers is that the standard processes --- get a network address, get a bootloader somehow, load a kernel, pull down an image --- are all pretty unauthenticated. You are trusting that the thing answering your dhcp query or the thing supplying you with an image is the thing you want to be talking to. For client machines this is bad enough, but what if you are wanting to deploy simple services? You want some greater degree of assurance.
What if you had some local store into which you could put some sort of credentials, say, a pgp key, or a certificate? It could be simple --- a compact flash plugged into the ide chain, or a usb keydrive plugged into an internal usb port. It could either contain your bootloader, or your firmware bootloader could use that credential to authenticate and encrypt bits of data. So, do a dhcp request, get a network address. Ask for a kernel with an embedded disk image. Take a couple hashes of what you get handed, use the certificate to securely query a service to verify that the hashes match. Start loading stuff. After the kernel boots, it could use that certificate to get other sensative data: pull down kerberos keytabs, ssh keys, etc. etc, from which more conventional methods of getting sensative data can be grabbed.
This seems to solve a few problems with the conventional method of doing netbooting:
How do I know I'm not getting trojaned binaries?
All you are trusting is dhcp. After that, you are verifying what you are getting through secure channels, and even if you use something like, say, nfs for the rest of your stuff, you can use this secure channel to set up ipsec or an ssl tunnel to the file service.
How do I even know I'm talking to the correct service to set up that initial channel, get the proper kernel, etc?
As long as you take reasonable steps to physically lock the machine (padlock the case shut, lock the machine to something, use a sane bios that prevents booting from any other device), there's no place where you could insert anything that would allow you to compromise the credentials. I can see a long chance if you could power up the machine but prevent it from doing anything else you might be able to plug in an external usb device and use the computer basically as an expensive usb hub and steal the credentials. If you limit yourself to the cf-ide solution, or make sure that you are plugged into a usb bus that does not leave the inside of the case, you should be able to limit that.
Ideas? Potential flaws?
Posted at: 01:14 | category: /computers/netboot | Link