🚀 go-pugleaf

> nwaltham@my-deja.com wrote:
...
>> and disabling the floppy in the BIOS. It strikes me that the weakest
>> point, from a physical point of view is the tape backup. The tapes

If you are giving untrusted people physical access to a machine, you
can't expect high security.  If people are willing to steal tapes,
what's stopping them from stealing hard drives?  Also, the BIOS
password can probably be overridden somehow--I doubt that anyone would
manufacture a motherboard that would become useless if someone forgot
the BIOS password.  I could be wrong.

In comp.os.linux.misc Kenneth C Stahl <kstahl@lucent.com> wrote:
> A simple way is to use nfs to allow your linux file systems to be mountable
> from an NT or Windows 95/98 machine. To perform the backup, just mount the
> directories and then use any Windows backup program that offers password
> protection. If you have a slow network this may take a while, but at least
> it will be secure.

This is not necessarily secure.  Anyone sniffing packets can see the
contents of the backup, unencrypted.  Also, even if the network were
secure, this method would be no more secure than the Windows machine
being used, and even NT has been riddled with security problems.

> Another way would be to perform a cpio backup to tape on the linux box (tar
> is never a very good idea and the only reason it is still around is that
> there is a lot of legacy support for it) and then share that drive with an
> NT/Win95/98 box and copy the cpio file to a tape backup with password
> protection and then erase the tape that has the cpio file.

Is tar really that bad?  I've never had any problems with it, but I
haven't used cpio much, either.

Anyway, for encrypted backups, here is a method that might work for you:

1. As root, create yourself a pgp key pair.  See pgp documentation
   about this.  (Something like "pgpk -g" or "pgp -kg" depending on
   your version of PGP.)  Suppose you choose "BOFH <root@computer>" as
   your userid.

2. To do a level 0 dump of the root partition, using the program
"dump" (if the tape device is /dev/nst0a):

dump 0uf - / | pgpe -r "BOFH <root@computer>" | dd of=/dev/nst0a bs=32k
\_dump_____/   \_compress, encrypt__________/   \_throw it on tape____/

(Note that you might use the command 'pgp -fe "BOFH <root@computer>"'
instead, depending on your version of PGP.  Also note that no
password/passphrase is needed to encrypt, just later, if you need to decrypt.)

3. To restore files from that dump:

dd if=/dev/nst0a bs=32k | pgpv -f | restore ivf -

(Again, you may need to use 'pgp -f', depending on your version of PGP.)

If you are not familiar with dump/restore, you should read about
them.  The block size (bs) given to dd may need to be different, or
not necessary at all.  PGP should do compression when it encrypts, but
you might want to experiment with different compression programs--just
be sure you put them before the encryption.  You can also try using
cpio or tar instead for the dump/restore steps.

There are a couple potential problems with this system that I will
point out:

1. If someone got a hold of root's public key, they could steal a
   tape, put spoofed data on it, and replace it.  Then, they could
   smash up the computer (with their physical access), and you would
   reinstall the computer with their spoofed data.  You can prevent
   this by not letting anyone get root's public key (and obviously not
   root's private key!).  Alternately, you could sign the encrypted
   data, but it's hard to make this secure without being interactive.

2. If you lose root's home directory, you will have trouble restoring
   the encrypted data because you will not have root's private key.
   To get around this, make a backup of root's home directory that you
   keep physically secure.   Incidentally, I would recommend making an
   unencrypted backup that you keep as secure as you feel comfortable
   with.  (In fact, if it's feasible, I would recommend doing all your
   backups unencrypted, and keeping the tapes physically secure.)

3. It might be slow.  My guess is that with a reasonably fast processor,
   the bottleneck will be I/O, but I'm not sure.

Good luck!

Chris