[Dovecot] Shredding instead of deleting
Hi,
I have a wishlist item. Is there an appropriate place for me to post it? Basically, I would like to know that my email isn't recoverable from the local disk on the mail server after I delete it. So instead of just deleting the file from my Maildir, I'd like the option to exist for Dovecot to shred it.. Ie, overwrite the file with random data and/or null bytes before deletion. In the same way that GNU shred behaves:
https://www.gnu.org/software/coreutils/manual/html_node/shred-invocation.htm...
-- Mike Cardwell https://grepular.com/ https://twitter.com/mickeyc Professional http://cardwellit.com/ http://linkedin.com/in/mikecardwell PGP.mit.edu 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F
On 14.9.2011, at 16.46, Mike Cardwell wrote:
I have a wishlist item. Is there an appropriate place for me to post it? Basically, I would like to know that my email isn't recoverable from the local disk on the mail server after I delete it. So instead of just deleting the file from my Maildir, I'd like the option to exist for Dovecot to shred it.. Ie, overwrite the file with random data and/or null bytes before deletion. In the same way that GNU shred behaves:
Well, the choices are:
a) Patch Dovecot sources
b) Use a LD_PRELOAD library to override unlink()
c) Use a FUSE filesystem that replaces unlinks with shredding
d) Wait until I've finished making dbox code use lib-fs, and write a lib-fs wrapper plugin that replaces unlink()
I'm not anyway planning on distributing any of these solutions with Dovecot. It won't even work with newer copy-on-write filesystems (ZFS, BTRFS, etc.)
On 14/09/11 15:06, Timo Sirainen wrote:
I have a wishlist item. Is there an appropriate place for me to post it? Basically, I would like to know that my email isn't recoverable from the local disk on the mail server after I delete it. So instead of just deleting the file from my Maildir, I'd like the option to exist for Dovecot to shred it.. Ie, overwrite the file with random data and/or null bytes before deletion. In the same way that GNU shred behaves:
Well, the choices are:
a) Patch Dovecot sources
b) Use a LD_PRELOAD library to override unlink()
c) Use a FUSE filesystem that replaces unlinks with shredding
d) Wait until I've finished making dbox code use lib-fs, and write a lib-fs wrapper plugin that replaces unlink()
I'm not anyway planning on distributing any of these solutions with Dovecot. It won't even work with newer copy-on-write filesystems (ZFS, BTRFS, etc.)
Is there no general wishlist area for Dovecot then? I didn't necessarily expect the functionality to be packaged with Dovecot, but thought that somebody might pick up the idea and write a plugin for it if it was written down somewhere. From a privacy/security perspective, making sure deleted email isn't recoverable does have real value for some people. I did consider FUSE. I might tackle that one myself. I don't really have the expertise to modify Dovecot it's self though.
-- Mike Cardwell https://grepular.com/ https://twitter.com/mickeyc Professional http://cardwellit.com/ http://linkedin.com/in/mikecardwell PGP.mit.edu 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F
On 14/09/11 15:19, Steve Thompson wrote:
From a privacy/security perspective, making sure deleted email isn't recoverable does have real value for some people.
What would you do about backups?
I realise that there are lots of other areas where an email can be leaked. It only makes sense to address how Dovecot behaves on this list though. I also need to address this for my MTA's mail spool and client caches.
I will address your backup question, but I'd prefer if people don't expand on this. I currently use some open source software called Duplicity, which allows me to perform incremental, gnupg encrypted backups.
Also, all of my incoming email is automatically encrypted with my public GnuPG key as described here:
https://grepular.com/Automatically_Encrypting_all_Incoming_Email
Even though it is encrypted, I'd like the mail to be shredded on delete because the message headers are stored in plain text, even if the message bodies are encrypted.
-- Mike Cardwell https://grepular.com/ https://twitter.com/mickeyc Professional http://cardwellit.com/ http://linkedin.com/in/mikecardwell PGP.mit.edu 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F
On 14.9.2011, at 17.15, dovecot@lists.grepular.com wrote:
On 14/09/11 15:06, Timo Sirainen wrote:
I have a wishlist item. Is there an appropriate place for me to post it? Basically, I would like to know that my email isn't recoverable from the local disk on the mail server after I delete it. So instead of just deleting the file from my Maildir, I'd like the option to exist for Dovecot to shred it.. Ie, overwrite the file with random data and/or null bytes before deletion. In the same way that GNU shred behaves:
Well, the choices are: .. Is there no general wishlist area for Dovecot then?
There's my internal TODO list distributed with source code :)
I didn't necessarily expect the functionality to be packaged with Dovecot, but thought that somebody might pick up the idea and write a plugin for it if it was written down somewhere.
I guess some wishlist page could be added to wiki, but I don't know if it would be all that useful. Few people want to code features they don't want themselves, and things I want to add are already being added to my own TODO list.
From a privacy/security perspective, making sure deleted email isn't recoverable does have real value for some people. I did consider FUSE. I might tackle that one myself. I don't really have the expertise to modify Dovecot it's self though.
The LD_PRELOAD way would be simple. Probably 10-20 lines of C code for something that would replace unlink()s to mail files with fork+exec to /usr/bin/shred.
On 14/09/11 15:26, Timo Sirainen wrote:
From a privacy/security perspective, making sure deleted email isn't recoverable does have real value for some people. I did consider FUSE. I might tackle that one myself. I don't really have the expertise to modify Dovecot it's self though.
The LD_PRELOAD way would be simple. Probably 10-20 lines of C code for something that would replace unlink()s to mail files with fork+exec to /usr/bin/shred.
Simple for somebody who can code in C you mean :)
-- Mike Cardwell https://grepular.com/ https://twitter.com/mickeyc Professional http://cardwellit.com/ http://linkedin.com/in/mikecardwell PGP.mit.edu 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F
On 14.9.2011, at 18.05, dovecot@lists.grepular.com wrote:
The LD_PRELOAD way would be simple. Probably 10-20 lines of C code for something that would replace unlink()s to mail files with fork+exec to /usr/bin/shred.
Simple for somebody who can code in C you mean :)
I have no idea if this works (or even compiles), it's based on a web page I found:
#define _GNU_SOURCE #include <stdio.h> #include <unistd.h> #include <dlfcn.h>
int unlink(const char *path) { static int (*libc_unlink)(const char *) = NULL; char *args[3]; int status;
if (libc_unlink == NULL) *(void **)(&libc_unlink) = dlsym(RTLD_NEXT, "unlink"); if (strstr(path, "Maildir/") != NULL) { args[0] = "/usr/bin/shred"; args[1] = path; args[2] = NULL; switch (fork()) { case -1: return -1; case 0: execve(args[0], args); exit(99); default: if (wait(&status) < 0) return -1; } if (WIFEXITED(status) && WEXITSTATUS(status) == 0) return 0; errno = ENOENT; /* not really correct, should maybe check it properly */ return -1; } else { libc_unlink(path); } }
On 14/09/11 16:19, Timo Sirainen wrote:
The LD_PRELOAD way would be simple. Probably 10-20 lines of C code for something that would replace unlink()s to mail files with fork+exec to /usr/bin/shred.
Simple for somebody who can code in C you mean :)
I have no idea if this works (or even compiles), it's based on a web page I found:
Thanks. That gives me an excellent starting point. I'll have a play with this code next week when I have some free time.
-- Mike Cardwell https://grepular.com/ https://twitter.com/mickeyc Professional http://cardwellit.com/ http://linkedin.com/in/mikecardwell PGP.mit.edu 0018461F/35BC AF1D 3AA2 1F84 3DC3 B0CF 70A5 F512 0018 461F
participants (4)
-
dovecot＠lists.grepular.com
-
Mike Cardwell
-
Steve Thompson
-
Timo Sirainen