[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Mutt & tmp files



Florian Bantner wrote:

> I am recently busy with email-security. I'm using Mutt and GnuPG
> which works greate for me. But one point did attract my attention:
> 
> When writing a new mail which I intend to encrypt via gpg, mutt
> creates a tmp file (normaly unter /tmp/.mutt*) which it uses to
> 'comunicate' with Vim.

Or emacs, or whatever editor you prefer, yes.

> This file lasts as long the vim-session is
> running. Vim then saves the changes to the file and gives execution
> back to Mutt.
> 
> What I don't like is: First the tmp file is readable by root.

All files are readable by root. Root has access to /dev/mem too, so he
could potentially get at it even if it wasn't written to disk. Root is
God. Anything you do on the system is potentially visible to root.

> I do
> know that there are other ways for root so that he can access the
> mail-content, but simply reading files seems a little bit to easy.

It's a temporary file, so it won't be visible after you've sent the
mail.

> Second and more important: When a file is created on disk it
> occupies physikal space on the disk. When its deleted again, the
> space is in no way 'cleaned', but stays on the disk until it is
> accidentaly overwritten. Even than you can recreate it.

That depends on what filesystem you're using. Granted, not many people
use filesystems that take care to prevent recovery of deleted files, but
if you're really that worried about someone getting at your messages,
that's one option. If you're root, that is.

Also note that root owns sendmail, or whatever MTA you're using. If he
really wants to read your mail, it would be much easier for him to do it
by configuring the MTA to silently copy him on all your messages, so all
this concern about temporary files and de-allocated disk sectors seems a
bit silly to me.

Your mail can also be spied on by packet sniffers or a compromise of the
mail servers of your correspondents.

> It's not hard to imagine situations where this is bad. But what
> to do against?

Well, I suppose you could encrypt your email, but that requires everyone
you correspond with to be able to decrypt it to read it.

The bottom line, though, is that if you don't trust root, don't use his
machine, or allow your packets to be routed through his machine (good
luck on that one if you're on the same hub). Root can do whatever he
likes and you can't stop him.

Craig



Reply to: