Re: Shred mount option for ext4?
On Oct 31, 2006 15:14 -0500, Nikolai Joukov wrote: 1. One of the patches performs N overwrites with configurable patterns (can comply with NIST and NISPOM standards). Because of the transaction compaction we had to separately add overwriting as separate transactions. Fortunately, the whole procedure is still atomic due to the orphan list. The problem that we have right now is per-file syncing of dirty data buffers between overwrites. We sync the whole device at the moment. Did anyone discuss doing this with crypto instead of actually overwriting the whole file? It would be pretty easy to store a per-file crypto key in each inode as an EA, then to delete the file all that would be needed would be to erase the key in a secure matter (which is a great deal easier because inodes don't move around on disk). The drawback is there is a runtime overhead to encrypt/decrypt the file data, but honestly, if people care about secure deletion don't they also care about security of the undeleted data also? By having an (unknown to the user) per-file crypto key then if the file is deleted the user can also plausibly deny the ability to recover the file data even if they are forced to surrender their key. Cheers, Andreas -- Andreas Dilger Principal Software Engineer Cluster File Systems, Inc. - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Shred mount option for ext4?
Andreas Dilger wrote: On Oct 31, 2006 15:14 -0500, Nikolai Joukov wrote: 1. One of the patches performs N overwrites with configurable patterns (can comply with NIST and NISPOM standards). Because of the transaction compaction we had to separately add overwriting as separate transactions. Fortunately, the whole procedure is still atomic due to the orphan list. The problem that we have right now is per-file syncing of dirty data buffers between overwrites. We sync the whole device at the moment. Did anyone discuss doing this with crypto instead of actually overwriting the whole file? It would be pretty easy to store a per-file crypto key in each inode as an EA, then to delete the file all that would be needed would be to erase the key in a secure matter (which is a great deal easier because inodes don't move around on disk). This is an interesting idea with some annoying implementation details. For example, we would still need to shred that data block used to store the EA in order to prevent key recovery. Also interesting to note that various people are putting encryption into various offload parts which could be useful in this context. The drawback is there is a runtime overhead to encrypt/decrypt the file data, but honestly, if people care about secure deletion don't they also care about security of the undeleted data also? By having an (unknown to the user) per-file crypto key then if the file is deleted the user can also plausibly deny the ability to recover the file data even if they are forced to surrender their key. Cheers, Andreas -- I think that having the data encrypted on disk is a generically useful feature, but in this case it might not count for much since the key is stored right next to the data in that EA... ric - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Shred mount option for ext4?
1. One of the patches performs N overwrites with configurable patterns (can comply with NIST and NISPOM standards). Because of the transaction compaction we had to separately add overwriting as separate transactions. Fortunately, the whole procedure is still atomic due to the orphan list. The problem that we have right now is per-file syncing of dirty data buffers between overwrites. We sync the whole device at the moment. Did anyone discuss doing this with crypto instead of actually overwriting the whole file? It would be pretty easy to store a per-file crypto key in each inode as an EA, then to delete the file all that would be needed would be to erase the key in a secure matter (which is a great deal easier because inodes don't move around on disk). Encryption is another possible secure deletion solution. Usually it is used by systems that already encrypt the data anyways. In that case the key management and run-time overhead costs are already paid. The drawback is there is a runtime overhead to encrypt/decrypt the file The difference is that in case of encryption there are overheads for read and write operations whereas in case of overwriting there are overheads only for infrequent unlink/truncate operations. I think that having the data encrypted on disk is a generically useful feature, but in this case it might not count for much since the key is stored right next to the data in that EA... Agreed. Key management is a big issue in any encryption system. In this particular solution the key management is simple but there is also no real protection of the live data. Nikolai. - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Shred mount option for ext4?
Sorry if this has been discussed already, I couldn't find anything in the list archive about it. What about adding the possibility of shredding or erasing free blocks on an ext4 filesystem? I value my privacy and the privacy of the people I host, and I often use shred(1) when erasing files from my server. The goal is to avoid that either a hacker or a post-mortem analysis gets ancien data from my disk. There are three problems with this approach: - I may forget to use shred sometimes - some files are automatically created and then removed (mails in spool) - data may be replicated in the journal and thus still present on disk I could use an encrypted filesystem everywhere, but in many countries, one is required to reveal her encryption key to authorities if they have a court order (UK for example). I think it would be quite easy to add a mount time option to ext4 filesystems asking that freed blocks are cleared or erased with random data? We could have for example: - free=clear|zero|shred (default clear, do nothing, zero means writing zeroes over the block, useful against attackers trying to recover data from a file system without physical access to it, and shred useful against post-mortem analysis of the physical surface) - shred-passes=N (number of passes when using the free=shred option, a negative number meaning writing values from 0 to -N onto the block) Some people (me included) would most likely accept the time penalty of using this option on selected filesystems (as well as the reduced lifetime of the disks because of the extra writes). I would contribute a proof-of-concept code, but I'm going to leave for a one-month vacation and will have a very bad connection until December. However, if noone jumps on that, I will likely code that when I go back unless someone beats me on it. In the meantime, I'd like to get people thoughts about it. Sam -- Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/ - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Shred mount option for ext4?
On Tue, Oct 31, 2006 at 11:36:11AM +0100, Samuel Tardieu wrote: I value my privacy and the privacy of the people I host, and I often use shred(1) when erasing files from my server. The goal is to avoid that either a hacker or a post-mortem analysis gets ancien data from my disk. There are three problems with this approach: - I may forget to use shred sometimes - some files are automatically created and then removed (mails in spool) - data may be replicated in the journal and thus still present on disk I could use an encrypted filesystem everywhere, but in many countries, one is required to reveal her encryption key to authorities if they have a court order (UK for example). Interesting. I'd say that you don't have to cooperate to get yourself convicted (i.e.: the right to remain silent). Over here in .nl you do have to cooperate to decrypt data from a suspect other than yourself, but you don't have to for your own data. I think it would be quite easy to add a mount time option to ext4 filesystems asking that freed blocks are cleared or erased with random data? We could have for example: - free=clear|zero|shred (default clear, do nothing, zero means writing zeroes over the block, useful against attackers trying to recover data from a file system without physical access to it, and shred useful against post-mortem analysis of the physical surface) - shred-passes=N (number of passes when using the free=shred option, a negative number meaning writing values from 0 to -N onto the block) FWIW, the idea that you need to rewrite 35 times doesn't longer hold. Modern drives use PRML encoding techniques, so a few random writes are enough if you're really paranoid. See the Epilogue section in Gutmann's paper at http://www.cs.auckland.ac.nz/~pgut001/pubs/secure_del.html . In practice a single overwrite is enough because of the sheer size of the task to reproduce the overwritten data. Compare it with a painting that was overwritten with white paint. Sure when you use a microscope you might be able to figure out some of the original color of the paint below the white, but it will take years to reproduce it. So far we haven't found a customer willing to wait a few years for his data... Some people (me included) would most likely accept the time penalty of using this option on selected filesystems (as well as the reduced lifetime of the disks because of the extra writes). Why don't you just make a libc wrapper for the unlink(2) system call? (A modified libc.so should do as well). That way it will work for all of your applications on all filesystems. Erik -- +-- Erik Mouw -- www.harddisk-recovery.com -- +31 70 370 12 90 -- | Lab address: Delftechpark 26, 2628 XH, Delft, The Netherlands - To unsubscribe from this list: send the line unsubscribe linux-ext4 in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
