I checked out purgefs - looks pretty theoretical.  It's an IEEE thing 
that someone has been playing with, but I found no code/how-to's.  The 
authors have some other layering filesystem projects.  Looks promising 
for the future.

Having a filesystem not available to root would be nice.

George Toft, CISSP, MSIS
623-203-1760

"That which does not kill us makes us stronger."



der.hans wrote:
> Am 05. Oct, 2006 schwätzte JT Moree so:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> George Toft wrote:
>>
>>> Requirements:
>>> 1. Deleted files (say, qmail messages after pickup) are shredded upon
>>> deletion.  Immediately upon delete.  Since an application is performing
>>> the delete, I must assume "rm" is not being issued, so I can't
>>> substitute "shred" in its place.
>>
>>
>>> What about #1?  Any ideas?
>>>
>>
>> if you dont control the application how are you going to do anything
>> about it anyway?  If you do control the app then just call the libraries
>> to do the shredding or make a system call to shred or write your own
>> shred routine.
>>
>> But keep in mind that on journalling file systems and most modern
>> filesystems the shred command is not 100% effective since the OS may
>> move the file without your knowing about it.
> 
> 
> Most modern disks also do funky stuff and lie to the OS.
> 
> Would having the filesystem be encrypted and not available to root take
> care of the issue?
> 
> If the drive is physically stolen the items that were still in the queue
> are even more vulnerable than the deleted items.
> 
> I asked on the LOPSA irc channel about a filesystem that would do a shred.
> 
> LD_PRELOAD came up there as well.
> 
> As did a suggestion for an encrypted filesystem that shreds all unused
> blocks every 15 minutes and a suggestion for a circular filesystem.
> 
> purgefs came up. I just glanced at it. Looks interesting.
> 
> http://www.am-utils.org/docs/purgefs/index.html
> 
> Another almost-suggestion was to automagically GPG stuff as it enters the
> queue such that only the intended recipient can open it.
> 
> Would a trojaned libc be able to circumvent all these things? In other
> words, should all the apps that might be used be statically compiled and
> sucked in to memory at boot? Would that be enough?
> 
> ciao,
> 
> der.hans
> 
> 
> ------------------------------------------------------------------------
> 
> ---------------------------------------------------
> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
> To subscribe, unsubscribe, or to change  you mail settings:
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change  you mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss