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
(text/plain)