<<< Date Index >>>     <<< Thread Index >>>

Re: [PATCH] Remove absolute paths from gpg.rc



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