[NMLUG] backup storage trade

[deathandtaxes at caglan.net (Dan Parrish)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Aaron NMLUG-EV wrote:
| On Sat, 2004-12-04 at 08:42, Jody Harris wrote:
|
|>Dan Parrish wrote:
|>
|>>As for the privacy issue, that's a sticky one.  I'm not sure if you can
|>>encrypt a folder, but I know you can encrypt a partition.  Perhaps if
|>>you had a separate partition that was all encrypted, it'd be a bit more
|>>secure for the client who's uploading their junk for backup purposes.
|
|
| I have considered that.  You can also do a partition-on-a-file,
| and mount via loopback.  The problem is that ANY change
| to the partition, and the WHOLE partition-on-a-file file gets backed up.
| I'm still thinking I would run a script to maintain
| a copy of the critical stuff, but every file is encrypted.
| At least that way, backup load is limited to new/changed FILES.
|
| Not a great idea, but its all I have right now...
|
|
|
| _______________________________________________
| NMLUG mailing list
| NMLUG@nmlug.org
| http://www.nmlug.org/mailman/listinfo/nmlug

Here's how I interpret the current state on this issue:

We want a host that has different directories encrypted and only
readable to users with the correct passkey.  In these directories, we
want a good incremental backup solution.  I'd use rdiff-backup for the
backup solution itself, but there's other alternatives as well.  The
main issue is the secure encrypted filesystem.

I really don't think there's a simple, elegant solution at present.  The
big problem is that the remote host's superuser could always get access
to your files.  The only way around this would be using an encrypted
filesystem that only the client machine has the key for.  However, the
only way we know of to get encrypted filesystem is by encrypting the
entire partition.

What if I had a big HD and set up a new 2GB partition for each client?
IOW, if someone wants to pay me $20 a year for secure backup, then I'd
just add another partition to that drive.  I'd have say 200GB, and I'd
only set up 2GB for the first client, and then I'd build new partitions
out of the free space on the HD.  I don't see any downside to this
solution, other than the fixed amount of space allocated.

However, does anyone here have a solution for only allowing the remotely
attached client to read the filesystem?  If only they had the passkey,
how would they use that passkey on the server?  If the passkey was ON
the server, and even if it's only user-readable, still the superuser
could get access to that key.  If someone can make a solution for this
problem, then I think the partition-per-client scheme would work best.
Perhaps there's a way to have the ssh session set an environment
variable that contains the passkey, and have the remote machine attempt
decryption of the files based on that environment variable?

Any other thoughts on this issue?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFBtpF3nURHNoE9YE4RAnWlAJ4n+ZPdZgiMdhCVsg9GbUOuQoeEEwCghT8m
88D5APHa/pnrHjPtRLLEt5s=
=XbGM
-----END PGP SIGNATURE-----