s1sw
asked on
Linux: change filesystme calls deleting files from RM to WIPE on mail server Communigate
Hi experts :)
I have a challenge and hope to be in the right place to find ideas or solutions :)
I need to install a dedicated mail server for a customer so it's emails are forensically unrecoverable after they've been deleted. We are talking about 2 150 user server, with around 30 domains.
I am evaluating Communigate Pro and Zimbra, and actually any postfix implementation (but I'd then need to add all the add ons for webmail, calendar and contact sync etc...) I could tweak to use WIPE instead of RM command so files are overwritten and then return free space.
How would you approach this?
I thought about encfs and encryptfs or truecrypt but this would simply not be a good idea: in case of a forensic action they'd find the server, dd the partitions and find them readable and mounted. So emails my customer wants to delete should just not be there and not be recoverable.
MY ACTUAL QUESTION IS THIS:
So I thought about tweaking the way the system deals with delete calls. Mail servers create single files for each email plus log files.
Communigate Pro is my first pick. open, read, write, lseek and unlink are the calls their C++ based system issues to the filesystem, I guess remove is used too... open, creat, close, read, write, lseek, unlink, remove, fcntl, stat should be the list..
How do I change the underlying system so the app requests a remove / unlink and this uses a wipe program to deal the comamnd.
My goal is to change the OS so the application does not understand things are different and deletes emails with wipe command, a 7 pass would be enough
Plus I'd like a script to erase free disk space portions via crontab, suggestions?
Logs would obviously be erased too.
I'm using a Ubuntu 10.04 lts 32bit but am evaluating to move on centos 64 bit that supports zimbra and communigate, as said zimbra would be fine just as communigate as long as it has no database with email information in it.
Cheers and hope to read interesting replies :))
I have a challenge and hope to be in the right place to find ideas or solutions :)
I need to install a dedicated mail server for a customer so it's emails are forensically unrecoverable after they've been deleted. We are talking about 2 150 user server, with around 30 domains.
I am evaluating Communigate Pro and Zimbra, and actually any postfix implementation (but I'd then need to add all the add ons for webmail, calendar and contact sync etc...) I could tweak to use WIPE instead of RM command so files are overwritten and then return free space.
How would you approach this?
I thought about encfs and encryptfs or truecrypt but this would simply not be a good idea: in case of a forensic action they'd find the server, dd the partitions and find them readable and mounted. So emails my customer wants to delete should just not be there and not be recoverable.
MY ACTUAL QUESTION IS THIS:
So I thought about tweaking the way the system deals with delete calls. Mail servers create single files for each email plus log files.
Communigate Pro is my first pick. open, read, write, lseek and unlink are the calls their C++ based system issues to the filesystem, I guess remove is used too... open, creat, close, read, write, lseek, unlink, remove, fcntl, stat should be the list..
How do I change the underlying system so the app requests a remove / unlink and this uses a wipe program to deal the comamnd.
My goal is to change the OS so the application does not understand things are different and deletes emails with wipe command, a 7 pass would be enough
Plus I'd like a script to erase free disk space portions via crontab, suggestions?
Logs would obviously be erased too.
I'm using a Ubuntu 10.04 lts 32bit but am evaluating to move on centos 64 bit that supports zimbra and communigate, as said zimbra would be fine just as communigate as long as it has no database with email information in it.
Cheers and hope to read interesting replies :))
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
appreciate feedbacks...saw some useful references though it may not direct fulfill the needs, it serve well in being aware and probably chance to leverage further..e.g
Inotify is a Linux kernel feature that monitors file systems and immediately alerts an attentive application to relevant events , such as a delete , read , write , and even an unmount operation.
http://www.ibm.com/developerworks/linux/library/l-ubuntu-inotify/index.html
SystemTap provides a simple command line interface and scripting language for writing instrumentation for a live running kernel plus user- space applications.
http://www.sourceware.org/systemtap/
maybe for a start is to profile (via taps & monitor) appl of interest to see its file activity and in particular deletion....
Inotify is a Linux kernel feature that monitors file systems and immediately alerts an attentive application to relevant events , such as a delete , read , write , and even an unmount operation.
http://www.ibm.com/developerworks/linux/library/l-ubuntu-inotify/index.html
SystemTap provides a simple command line interface and scripting language for writing instrumentation for a live running kernel plus user- space applications.
http://www.sourceware.org/systemtap/
maybe for a start is to profile (via taps & monitor) appl of interest to see its file activity and in particular deletion....
"Forensically Unrecoverable" can only be achieved by converting the disk platter to metal filings. Anything short of that is recoverable - given sufficient resources. How unrecoverable are you aiming for?
agree with duncan_roe, having the "wipe command, a 7 pass would be enough " may not warrant forensic unrecoverable, if we will to adhere to the definition of unrecoverable :)
Nonetheless, the link below talks abit more on the wiping. In short, if you really want unrecoverable, degaussing or physical destruction would give assurance but not practical in your operations. Hence, staying balance would be the way. The article even mention one way pass is sufficient, in all, we are just saying to make it harder to recover and deter logical attempts.
@ http://www.anti-forensics.com/disk-wiping-one-pass-is-enough
Nonetheless, the link below talks abit more on the wiping. In short, if you really want unrecoverable, degaussing or physical destruction would give assurance but not practical in your operations. Hence, staying balance would be the way. The article even mention one way pass is sufficient, in all, we are just saying to make it harder to recover and deter logical attempts.
@ http://www.anti-forensics.com/disk-wiping-one-pass-is-enough
unlink only removes 1 link to a file. There may be others. Even if there are not, the file may be open to some process. Actual return of file system blocks does not occur until there are no links and the open count for the file drops to zero. That is not a user-accessible event, but it's what you need to change. So you are looking at a modification to Linux. When blocks are freed, you want to write some configurable number of patterns over them first. I would think you would want a new file attribute, user settable, to indicate files that are to be given this treatment. Perhaps you could do it as a directory attribute - that would save the need to modify user software to set the attribute on individual files.
Your first step would be to implement the block overwriting mechanism to all files unconditionally. If that doesn't slow the system to a crawl, then you could leave it.
Your first step would be to implement the block overwriting mechanism to all files unconditionally. If that doesn't slow the system to a crawl, then you could leave it.
ASKER
Hi all and thanks for commenting on my question again.
> maybe for a start is to profile (via taps & monitor) appl of interest to see its file activity and in particular deletion....
Yep definitely, I'll try to dig how to use these tools hopefully achieveing the desired information on how the application works. After that I need to edit the command received by the filesystem so it actually turns into a wipe.
Anyways I expect I will get a more specific reply from Communigate on software's workflow with email files... and on the actual call used when deleting emails hence the one to actually edit/alias.
So let's say I actually know the specific calls used hence to edit, if I was to edit the system calls remove, unlink [and possibly have a look at all open, creat, close, read, write, lseek, unlink, remove, fcntl, stat] how could I proceed?
What I mean is: I know rm is a file, +x to be an executable, placed in /sbin or wherever maybe linked to another place etc. If I was to edit how rm works on a system I would create a script that handled eventual parametres and link rm to that script.
I need this for system calls and have no ideas on how they work :( are they a file or command so I can edit how they are used?
@Duncan_roe: I probably am missing a few points...
but > Your first step would be to implement the block overwriting mechanism to all files unconditionally. If that doesn't slow the system to a crawl, then you could leave it.
sounds perfect for me. Do you know how to do that? Are we speaking of customizing kernel or is there any other route?
As of wiping tecqniques: I am aiming to first be able to give the wipe command to the system, then passes number will get real consideration 1/3/7/35 - obviously phisical destruction couldn't work on a system ;p
> maybe for a start is to profile (via taps & monitor) appl of interest to see its file activity and in particular deletion....
Yep definitely, I'll try to dig how to use these tools hopefully achieveing the desired information on how the application works. After that I need to edit the command received by the filesystem so it actually turns into a wipe.
Anyways I expect I will get a more specific reply from Communigate on software's workflow with email files... and on the actual call used when deleting emails hence the one to actually edit/alias.
So let's say I actually know the specific calls used hence to edit, if I was to edit the system calls remove, unlink [and possibly have a look at all open, creat, close, read, write, lseek, unlink, remove, fcntl, stat] how could I proceed?
What I mean is: I know rm is a file, +x to be an executable, placed in /sbin or wherever maybe linked to another place etc. If I was to edit how rm works on a system I would create a script that handled eventual parametres and link rm to that script.
I need this for system calls and have no ideas on how they work :( are they a file or command so I can edit how they are used?
@Duncan_roe: I probably am missing a few points...
but > Your first step would be to implement the block overwriting mechanism to all files unconditionally. If that doesn't slow the system to a crawl, then you could leave it.
sounds perfect for me. Do you know how to do that? Are we speaking of customizing kernel or is there any other route?
As of wiping tecqniques: I am aiming to first be able to give the wipe command to the system, then passes number will get real consideration 1/3/7/35 - obviously phisical destruction couldn't work on a system ;p
This would be a customised / new kernel module.
Maybe the folks who look after Secure Linux would be interested - you could try asking.
I think overwriting with random patterns would be best - if it's not too slow to get them
Maybe the folks who look after Secure Linux would be interested - you could try asking.
I think overwriting with random patterns would be best - if it's not too slow to get them
am thinking if there is one driver that handle all the file system, meaning all these cmds will eventually come to it passing the file handle and size to it. with that, it may be easier, else handling the various option is not going to be efficient in a long run e.g. system go for new upgrade patching etc
Yes I would expect it would be done in the Virtual File System Layer. It might still be able to check a "scrub on delete" attribute if doing all files proved to be too slow (as I sort-of expect it would).
ASKER
Any references on how to do that?
BTW, what is behind an unlink(2) call? That could be it actually.
BTW, what is behind an unlink(2) call? That could be it actually.
Actually I am doing some check in the linux man and this link to check on the various API is useful, esp the "Referenced By" section which tells you which parent API is using it. Probably the more of it listed, the more is the right API to focus on to "replace".
@ http://linux.die.net/man/
Type in the API and it will show you the chunk of details you will want to know. Did it on rm and unlink.
@ http://linux.die.net/man/1/rm
@ http://linux.die.net/man/2/unlink
From the rm, it states it does unlink function too, not sure it calls unlink though. So I check on "unlink" and saw it referenced by syscalls. Meaning it is one of the system calls. I did a check if rm is around , nope. But do saw there is rmdir which is to delete directory. Hence, I am suspecting we are closer if we "replace" the unlink, and rmdir. Not sure if that is the right track but unlink will definitely be one of the key ones. But only see the header files hence will need to identify the kernel source files (with those API) that need to be recompiled
@ http://linux.die.net/man/2/syscalls
Also there are interesting API (see below) for your information.
shred - overwrite a file to hide its contents, and optionally delete it @ http://linux.die.net/man/1/shred
tmpwatch - removes files which haven't been accessed for a period of time @ http://linux.die.net/man/8/tmpwatch
symlinks - symbolic link maintenance utility - It scans directories for symbolic links and lists them on stdout, often revealing flaws in the filesystem tree. @ http://linux.die.net/man/8/symlinks
@ http://linux.die.net/man/
Type in the API and it will show you the chunk of details you will want to know. Did it on rm and unlink.
@ http://linux.die.net/man/1/rm
@ http://linux.die.net/man/2/unlink
From the rm, it states it does unlink function too, not sure it calls unlink though. So I check on "unlink" and saw it referenced by syscalls. Meaning it is one of the system calls. I did a check if rm is around , nope. But do saw there is rmdir which is to delete directory. Hence, I am suspecting we are closer if we "replace" the unlink, and rmdir. Not sure if that is the right track but unlink will definitely be one of the key ones. But only see the header files hence will need to identify the kernel source files (with those API) that need to be recompiled
@ http://linux.die.net/man/2/syscalls
Also there are interesting API (see below) for your information.
shred - overwrite a file to hide its contents, and optionally delete it @ http://linux.die.net/man/1/shred
tmpwatch - removes files which haven't been accessed for a period of time @ http://linux.die.net/man/8/tmpwatch
symlinks - symbolic link maintenance utility - It scans directories for symbolic links and lists them on stdout, often revealing flaws in the filesystem tree. @ http://linux.die.net/man/8/symlinks
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Mind you, shred as mentioned by breadtan in http:#a35452102 might satisfy your needs. You would need to ensure your mail clients always use it to delete emails. Should be fine if the clients use Maildir, not so sure about the older Mbox
ASKER
actual solution was not found
I believe ecryptfs /truecrypt for the mount points required plus tmp obviously could do, having a wipe free space cron job.
not what I wanted but seems to be the easy way for it.
does not deserve knowledge base appliance since it does not actually solve.
sharing my costly points with who partecipated to the discussion
I believe ecryptfs /truecrypt for the mount points required plus tmp obviously could do, having a wipe free space cron job.
not what I wanted but seems to be the easy way for it.
does not deserve knowledge base appliance since it does not actually solve.
sharing my costly points with who partecipated to the discussion
ASKER
(Users are not the kind that would preventively not transfer confidential information. I know emails would be on clients (remote wipe and similar stategies) and sender's server and probably elsewhere too (sometimes you hear of ISP forced to allow tracking of all data realtime to gov etc, sounds an immense thing to accomplish though and is off topic), but for the kind of moderate legal threat no one would go so deep...)
So the changing rm to wipe command would be my solution but I actually don't know if the command given by the app is rm.
As said the command is given via linux file system calls: open, creat, close, read, write, lseek, unlink, remove, fcntl, stat
So the C++ application gives commands via the above to the filesystem.
What I guess is the road to go is take all commands involved with deletion and see what they actually do on the linux filesystem and understand where to edit their modus operandi. What I' m missing is how to deal that!
I'm on debian 6 squeeze or ubuntu 10.04 lts and CentOS would be great too.
So if the file system calls recall the rm command then I'd go for changing the command via symlink (guess no parameters would be passed) and test how cpu and disk usage rise (being a mail server, tons of files get written and deleted all the time) or script as suggested that would deal with everything in the correct way.
The cron to wipe .trash and or free space is another solution I'm evaluating but is passive and I-d go for it only in case the first was too high usage on physical resources. I would look for a free space wipe that would deal with a portion of disk or have
BTW you actually handed a few other excellent points to deal with: users and administrator limiting and logging. Having said this the admin won't be allowed to interact with the system if not via webmail admin interface.