How secure is ext3?

[Kirsle]

I've been searching Google for ext3 and have a couple of questions about it in terms of its security.

1. Where is the journal file, and what does it log? i.e. if I rename a file, does the journal log that "file xxx was renamed to yyy"? Or, if I change the file's contents, does it log "file yyy used to have this content: ... now it has this: ..."

If the journal logs too much information about a file like that, it would be a whole other security concern in itself (like, you'd "securely delete" a file, but the log would still have what used to be in the file).

If the journal does store a whole lot of information, is there a way to blank out the journal, or reset it?

2. A few articles about ext3 mention that deleted files are very difficult to recover. Does it write zeroes over the file's contents on the disk, or just to the pointers on each block so that the file system couldn't link one end of the file to the other?

Is there a utility that could fill up the entire, unlinked portion of the hard drive, wiping out any loose "deleted file data" that isn't currently linked to an existing file?

Thanks in advance.

-------------
Cuvou.com | My personal homepage
Project Fearless | My web blog

 

[thedaver]

I think the shortest answer for your query is that "ext3 was NOT designed as a secure filesystem. Don't try to make it fit that model."

It uses the journal to recover from unexpected crashes and unexpected hardware failures. The journal necessarily retains a lot of fs history - including your examples - to fulfill its mission of being a resillient fs.

ext3 is also not the highest performing fs either.

However, what you should infer from it being the de facto OS for most of the distros out today is that it is appropriate and suitable for the mainstream users as a default fs.

I would look elsewhere if you wanted secure controls on the fs' audit trail and history.







D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[zeland]

Is there a utility that could fill up the entire, unlinked portion of the hard drive, wiping out any loose "deleted file data" that isn't currently linked to an existing file?

The traditional way zero-ing out unused portions of your partition would be to use dd:

dd if=/dev/zero of=zero.txt

and then delete the file once the filesystem runs out of space.

--== Anything can go wrong. It's just a matter of how far wrong it will go till people think its right. ==--

 

[stefanwagner]

Wikipedia says, most Linux systems only write metadata to the journal:

http://en.wikipedia.org/wiki/Ext3

don't visit my homepage:

http://home.arcor.de/hirnstrom/bewerbung

 

[stefanwagner]

... and of course the logsize is very limited
by partition size
- space usable for files
- normal meta-information.

man mkfs.ext3

might be another source of interesting information.

don't visit my homepage:

http://home.arcor.de/hirnstrom/bewerbung

 

[Kirsle]

With this command:

dd if=/dev/zero of=zero.txt

Would you recommend doing this from a LiveCD so that the file system isn't being actively used? It seems like if some normal system log files wanted to save something at the wrong time they'd be competing with zero.txt and cause problems, or would that not be an issue?

-------------
Cuvou.com | My personal homepage
Project Fearless | My web blog

 

[zeland]

Technically, there would be a contention of disk space with any logging but that would be a non issue if you append ;rm -rf zero.txt at the end of your dd command. If you can afford to bring down your system do a dd via a liveCD, all the better.

--== Anything can go wrong. It's just a matter of how far wrong it will go till people think its right. ==--

 

[thedaver]

This conversation is going in peculiar directions. OP, what's the real goal you're trying to reach? I suspect we're answering minor details but the bigger question remains open.

D.E.R. Management - IT Project Management Consulting

http://www.dermanagement.com/

 

[Kirsle]

The real goal was just to find out any of the "gotcha's" to how ext3 might potentially make it difficult to securely delete or modify files, leaving no trace of their original contents or attributes (even the original name of the file).

-------------
Cuvou.com | My personal homepage
Project Fearless | My web blog

 

[mtodorov69]

The traditional way zero-ing out unused portions of your partition would be to use dd:

dd if=/dev/zero of=zero.txt

and then delete the file once the filesystem runs out of space.

The problem with this solution is that it does not erase journal. So, if a number of blocks is written down on disk in journal prior to committing, it is possible that it will remain there even after entire disk is used up by zero-ing a file.

Journal space is highly unlikely reported as a free disk space to write to, so essentially Kirsle's question hasn't been answered.
Sensitive information can still be extracted by reading from and grepping raw disk device or with special tools.