Sigh. If you've lost patience with this thread, and you don't want to read my long post, but you do still care about Mutt's security, please at least scroll down to where I talk about Peter Galvin, and follow the link. On Sun, Mar 18, 2007 at 08:44:44AM +0000, Dave wrote: > If you don't trust your own $PATH, there's something fundamentally > wrong with your environment. If you want extra $PATH security when > running Mutt, there's nothing stopping you from wrapping Mutt with a > $PATH sanitizer. This assumes that the user has enough of a clue to care. The problem with that assumption is, as I've already said, and everyone here already knows, most users don't. Which is fine if we're talking about vi, but as I've also said, mutt is designed explicitly to deal with untrusted data from an outside source (e-mail from the Internet), much of which is KNOWN to be malicious. If only the user were affected, that would be one thing. Ignorant users, by and large, will get what people who choose to stay ignorant always get. But we're talking about e-mail: Not only is the user affected, but potentially so is everyone who sends him mail, and everyone he subsequently sends mail to, and everyone on his network. That's an awful lot of potential damage to trust to any individual user's ability to deal with his own security, when we already know, most users are utterly clueless. Mutt can't afford to trust that the user will get his own security right, because in the overwhelming majority of cases, it just won't happen, and the user is potentially far from the only one affected when it goes wrong. Most of us remember when e-mail worms took down whole companies, and maybe even worked at one of those companies. You probably know someone who had their company directory stolen via such a bug. This stuff is NOT trivial. > The UNIX philosophy isn't to protect a user from himself any more > than the user himself decides to protect himself from himself. The Unix Philosophy works great in many, many cases, but is not universally the right solution. The Unix Philosophy sired a great many programs that were security abominations. Though to be honest, I don't think the Unix Philosophy has anything to do with what you just said... If you want to know what it's about, go here: http://www.catb.org/~esr/writings/taoup/html/philosophychapter.html > It's not Mutt's place to refuse to honor my $PATH just because IT > doesn't trust it. Sure it is. If Mutt can help the user get it right by enforcing minimally restrictive measures, how is that a bad thing? I could point you at numerous papers and books recommending against security-sensitive applications trusting the user's PATH, but I won't bother... you won't read them anyway, and if you really wanted to you could find them easily enough by searching your favorite search engine. Just for the sake of not being called a cop-out, I will provide one published by a renowned and verifiable Unix security expert: http://sunsite.uakom.sk/sunworldonline/swol-08-1998/swol-08-security.html Ooh, what's that you say, Peter? E-mail applications should not trust the user's PATH? Hmmm... Convenient that he named that example explicitly. You don't believe me that Peter Galvin is a renowned security expert? Search Google for "Peter Galvin security" -- that should convince you. > If I trust it, what's Mutt's problem??? If you have no clue, your trust is worthless. When we design the security of our applications, we have to assume that the user is completely clueless, because mostly they are. If you can specify the full path to your GPG installation, I really don't see what the big deal is. Clueless users will have the path configured for them by the nice people who package their OS, and everyone else can still do whatever they want. I can't see any sane argument for this being bad. Searching for applications via the PATH in a security-sensitive context is, was, and always will be a potential source of security problems. Is this a panacaea? Of course not. But security is a funny thing. Each individual measure that one takes effects usually only a relatively small change in overall level of security. You could argue that such a small difference makes it not worth losing a little flexibility, but you can make that argument, or one similar to it, about nearly every single measure you can put in your code. Eventually you will conclude that security is just not worth the effort, and not bother at all. But that's obviously the wrong approach. Taking this seriously has virtually no negative impact on the user: configure it once, however you chose to do so, and be done with it. Mutt already has a zillion things that MUST be configured when you start using it, so one more is totally negligible. The gain in security you get is small, but weighs more heavily against the miniscule inconvenience of having to pay attention to where your gpg binary is, if you happen not to be using your vendor's mutt package and gnupg package. The conclusion is that some kind of PATH protection should be included. I favor compile-time hardcoded path, which can be specified by configure option, and overridden in the config file by specifying a full path. I'd also really like to see a configure option for mutt refuse to run binaries in directories where the user has write access, enabled by default, but whatever. If you want or need this level of security, there's no reason it shouldn't be available. Some of it's already in mutt, and the rest is not difficult to include. > Besides, since gpg.rc is fairly standard, it's entirely trivial for > a trojan to simply replace your gpg.rc instead of your muttrc, and > 99% of users will never notice that their gpg has been hijacked by a > virus that's not even in their $PATH! Right. I already described a nearly trivial means for mutt to detect changes in the files it sources. That should go in too, ideally. It wouldn't affect the user AT ALL, but it would make them safer. > I guess the point I'm making is that the security implications of > $PATH are part of an entirely different discussion list > (comp.os.unix), and that our discussion here is ridiculous, since > most of the experts on the subject aren't even here. Ridiculous? I just backed up my argument with that of a known, verifiable expert. Where's yours? I seriously doubt you'll find any real security expert who will advocate that one should explicitly NOT attempt to securely call programs by either using absolute paths or by sanitizing the PATH variable. > Mutt should simply fit in with the rest of a POSIX system, so if > POSIX says that user applications should search $PATH for programs > because it's a tool available to a user to tell a program where to > look for another program Where does POSIX say that? > who the hell are we to deliberately break compatibility???) We are the people who know better... ;-) I conceed that I'm not an "expert" (a word which is much overused, I think) in security, but I am (or was, technically) a certified security professional, was senior security engineer for 2 years and did security for 4, and I do know a thing or two about which I speak. -- 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.
Attachment:
pgpUkMdz2vqPL.pgp
Description: PGP signature