Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

How secure is ext3?

Status
Not open for further replies.

Kirsle

Programmer
Jan 21, 2006
1,179
US
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
 
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
 
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. ==--
 
With this command:

Code:
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
 
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. ==--
 
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
 
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
 
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.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top