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.
pgp74CBRwcl8V.pgp
Description: PGP signature
