Re: [PATCH] Add $umask for mailboxes and attachments
I continue to think that the umask patch should't have been taken
into mutt. However, at this point, the decision is really
Brendan's.
That said, I think there are several questions to consider here:
- E-Mail systems are typically set up to create inboxes with rather
paranoid security settings (typically 0600); regardless of what
the user's umask is, e-mail privacy is protected by default.
Saving a message to a new folder should, by default, not expose
messages more broadly than they were exposed before. Therefore,
mutt should *never* create new folders with rights more lenient
than 0600.
- What's the typical reason for a lenient umask on a multi-user
system? People collaborating on some project through shared
directories, possibly with local cvs involved. On such systems,
though, it does indeed make sense to be more paranoid about e-mail
than about other user files. Another reason to protect e-mail
more tightly than other files the user creates.
(And yes, I have worked and continue to work on such systems.)
- Finally, temporary files are supposed to be private to the
application that creates them. There is no good reason whatsoever
to create these files with rights that are any more lenient than
0600.
Concluding, I see only a very limited number of cases in mutt in
which it really makes sense to defer to the user's umask (or a
configured one) in terms of file permissions; in almost all other
cases, 077 is the right umask to apply.
If you weigh the complexities involved -- a single umask(077) in
main.c vs. a decision about what to do each time a file is opened
--, and the risks that come with screwing up the more complex case,
then it's pretty clear to me that the single umask(077) is the way
to go.
Cheers,
--
Thomas Roessler <roessler@xxxxxxxxxxxxxxxxxx>
On 2007-03-17 00:05:49 -0400, Derek Martin wrote:
> From: Derek Martin <invalid@xxxxxxxxxxxxxx>
> To: Mutt Developers <mutt-dev@xxxxxxxx>
> Date: Sat, 17 Mar 2007 00:05:49 -0400
> Subject: Re: [PATCH] Add $umask for mailboxes and attachments
> Reply-To: mutt-dev@xxxxxxxx
> X-Spam-Level:
> X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.1.5
>
> On Fri, Mar 16, 2007 at 01:15:10PM +0100, Christoph Berg wrote:
> > Hi, and sorry for the late followup.
> >
> > Imho there are 3 issues left in the umask handling:
> >
> > #1: main.c sets umask(077) unconditionally. Should be removed.
>
> I'm sorry I missed the start of this thread. The umask patch is, IMO,
> yet another abomination of a security mistake. Here are some nice
> words from Thomas back in 2001 to support that idea.
>
> http://marc.info/?l=mutt-dev&m=98883584213566&w=2
>
> I once argued to let the user's umask be what mutt uses. I was wrong.
>
> The essential problem is that Mutt does not behave like other user
> programs. Rather than operating on data which can generally be
> assumed to be safe, as say vi would, Mutt is used PRIMARILY to process
> arbitrary untrusted data which comes from the Internet. Often the
> data mutt is manipulating is of a sensitive and/or personal nature.
> Attachments can contain sensitive data, and a user may unknowingly or
> carelessly expose that data due to their unfortunate choice of (their
> own) default umask value. Also setting the umask to something other
> than 077 could expose the user's passwords and/or encryption key
> passphrases, should Mutt segfault and leave behind a core dump. The
> requested feature set requires Mutt to set and reset the umask in a
> variety of different contexts. A bug in the implementation could
> expose encrypted e-mail which the sender does not wish anyone but the
> receiver to see. A user using Mutt at work could negligently expose
> confidential company data to a co-worker who should not have access to
> that data for security reasons.
>
> As Thomas advocated all the way back in 2001, Mutt should err on the
> side of caution, and make it difficult for users to accidentally
> expose sensitive data. Frankly, users are ignorant, and are all too
> willing to give up their security for the sake of convenience. If
> you don't believe this, take a security class, and you will have it
> proven to you in short order.
>
> [To say someone is ignorant is not inherently an insult, and is not
> meant as one here. It simply means, literally, that the person lacks
> knowledge.]
>
> Even relatively well-informed users are often surprised by what they
> don't know. How many people reading this thought of the core dump
> problem I just mentioned? What other kinds of attacks have you (or I)
> not imagined? Using a lax umask value probably opens up other forms
> of holes that no one involved in this discussion has yet thought of,
> as well. Organizations hire trained security professionals to develop
> written security policies because normal users -- even very technical
> ones -- are simply not competent to decide on their own security
> models. Users fight against these seemingly pointlessly restrictive
> policies tirelessly. But they are WRONG.
>
> In potentially serious cases such as this, Mutt should protect
> ignorant users from themselves. Is it so hard to change a file's
> permissions after it has been downloaded? Requiring that the user do
> this forces them to think about whether they really want to do this,
> and prevents ignorant or careless users from negligently exposing
> sensitive data.
>
> The umask issue has been brought up and shot down (or just simply
> ignored) numerous times, in 2000, 2001, 2003, 2005, and 2006. Let's
> not make the mistake of being lax about security just because the old
> guard who protected it vigilantly have relinquished Mutt's reigns.
> Mutt should enforce a umask of 077 if it is to remain the secure
> mailer that we all love it for being...
>
> --
> Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
> -=-=-=-=-
> This message is posted from an invalid address. Replying to it will result in
> undeliverable mail. Sorry for the inconvenience. Thank the spammers.
>