if someone knowledgeable enough has physical access to the running box, you can't keep the data private.
Thats true, but you can make it awfully hard to get the data. I know of someone who put his computer in a gun closet, which is a tall metal cabinet weighing many hundreds of pounds, secured with bolts inside the case to the cement wall in the basement. Could you get it? Sure: with enough effort and possibly explosives. You can secure a computer pretty well. Just think heavy and bolted to a wall. --STeve Andre'
If the box is running but no users are logged-in, why can't the data be encrypted and therefore private? This is my thinking about per-user home directory/partition encryption. Doug.
It can be. Use OpenSSL or GnuPG or PGP symmetrically (only store the passphrase in your head) in addition to volume/disk level encryption. Tar up your secret files, encrypt the tar file and then remove the secret files. When you need to read the secret files, decrypt the tar and then extract what you need. Wash, rinse and repeat. Cron a sh script to dd /dev/zero onto the home partition until it's full (don't want sophisticated guys viewing your unallocated space)... know what I mean? Man, this is getting a bit paranoid. -- View this message in context: http://www.nabble.com/new-home-box-for-secure-data-storage-tp20235167p20275760.html Sent from the openbsd user - misc mailing list archive at Nabble.com.
Most of your requests are pretty common and come up frequently enough you should be able to find the answers, but this part makes me wonder. So how does root have the key? Do you type it in everytime you do a backup or is there a file called "dontreadthis" in /root? You could maybe do some tricks with cfs but it's a guaranteed shot in I don't let people steal my computers.
Lets say the key is in a file. Lets encrypt that file with openssl and keep it in /root. Whoever runs the backup program is asked for the passphrase to unlock the file. The backup program then uses that file Of course there's the risk/benefit/cost analysis. Gun cabinets or safes bolted to the floor work but are expensive. I could get the same kind of deterrence if I installed a big rack-mount 12U server full of a dozen hard drives (think too heavy for one person to steal, assuming that they recognized it as a computer in the first place). Software encryption is free. Doug.
I'm confused, the encrypted volume cannot be backed up without a key? -- Some software money can't buy. For everything else there's Micros~1.
Sure, I could backup the encrypted volume. However, I'd rather back the data up as an unencrypted directory along with everything else. I don't know what's involved in e.g. restoring an accidentally deleted file from within an encrypted volume. I guess I'd treat it like a tarball in that its a file, mount it somewhere using the usual key and retreive the file, mount the user's encrypted volume and copy the file back where it belongs. Its likely that its me that's confused. Since what I'm contemplating doesn't seem to be mainstream, I'm assuming that backup and restore procedures aren't mainstream (e.g. have the kinks worked out) either. That assumption could be invalid. Doug.
And then someone steals your backup. Wouldn't it be more sophisticated, to secure the physical access (lock up the door, some security on the windows (the real one, not that crap from MS), if any) to the system and encrypt the backup (public-key comes to my mind). As mostly backup will be done on external media (DVD, CD, Tape, USB-Harddrives) It always depends on how paranoid you are (and as I remember you are more paranoid then the average ;-) ), how secret your data is. -- Mit freundlichen Gr|_en, Guido Tschakert _____________________________________________________________ SRC Security Research & Consulting GmbH Graurheindorfer Str. 149 a Tel: +49-228-2806-138 53117 Bonn Fax: +49-228-2806-199 http://www.src-gmbh.de Mob: +49-160-3671422 Handelsregister Bonn: HRB 9414 Geschdftsf|hrer: Gerd Cimiotti
Physical access to the apartment is as secure as possible given the lease (which is what is prompting this thread). As for the backup media, the total size of the backup set is about 50 GB and for off-site I want it to fit in the bank's small safety deposit box (CDs don't fit) so I'm thinking about using LTO-1 (LTO's will fit and LTO-1 is slow enough that a single IDE drive in a P-133 box should be able to keep it fed). This is a separate issue that I don't want to
Here's a possible way to make backups for users homes: Install boxbackup, create a configfile per user, add a line to .profile that runs boxbackup in snapshot modes everytime a user logs in or logs out. Boxbackup transfers and stores the backups encrypted. So no need to worry there. -- Michiel van Baak firstname.lastname@example.org http://michiel.vanbaak.eu GnuPG key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x71C946BD "Why is it drug addicts and computer aficionados are both called users?"
I'm not familiar with boxbackup (I'll look it up later). Something similar was that I figured that the encrypted images could be under, e.g. /enchome and the user's .profile may cause the encrypted volume to be mounted over their /home/<username> directory. Doug.
Then keep it off a computer. Otherwise look for solutions that have already been presented...because they work. - Eric
|Dave Jones||Re: OT: character encodings (was: Linux 2.6.20-rc4)|
|Greg Kroah-Hartman||[PATCH 17/36] sysdev: detect multiple driver registrations|
|Sam Ravnborg||Re: [PATCH] kbuild: fix make V=1|
|Nick Piggin||Re: [PATCH 0/24] make atomic_read() behave consistently across all architectures|
|Greg Kroah-Hartman||[PATCH 16/36] driver core: cpu: fix section mismatch in cpu.c:store_online|
|Stephen R. van den Berg||Re: [RFC] origin link for cherry-pick and revert|
|Junio C Hamano||Re: [PATCH 1/2] Teach git-describe to display distances from tags.|
|Johannes Schindelin||Re: [PATCH 2/2] git-svn: support fetch with autocrlf on|
|fantasy1215||Will tortoisesvn conflict with tortoisegit?|
|Junio C Hamano||Re: [PATCH 6/6] Teach core object handling functions about gitlinks|
|Jarek Poplawski||Re: [PATCH] flush_work_sync vs. flush_scheduled_work Re: [PATCH] PHYLIB: IRQ event...|
|Lennert Buytenhek||Re: Distributed Switch Architecture(DSA)|
|Daniel Schaffrath||Re: tcp bw in 2.6|
|Guo-Fu Tseng||Re: jme: UDP checksum error, and lots of them|
|Gerrit Renker||[PATCH 37/37] dccp: Debugging functions for feature negotiation|
|Claudio Jeker||Re: Vlan Tag on Vlan Tag (l2tunneling)|
|Josh Grosse||ssh/sshd challenge-response seems to have stopped working in -current|
|Pieter Verberne||File collision while using pkg_add|
|Tomas Bodzar||bsd: uvm_mapent_alloc: out of static map entries|
|Community First Financial||Teacher A+ Loan|
|Linux Kernel Mailing List||ath9k: Added get_survey callback in order to get channel noise|
|Linux Kernel Mailing List||tracing: protect reader of cmdline output|
|Linux Kernel Mailing List||kconfig: recalc symbol value before showing search results|
|Linux Kernel Mailing List||[ARM] 5185/1: Fix spi num_chipselect for lubbock|
|Linux Kernel Mailing List||swsusp: provide users with a hint about the no_console_suspend option|