Re: [PATCH] Remove absolute paths from gpg.rc
Warning: This post is quite long.
On Mon, Mar 19, 2007 at 11:51:37PM -0400, Derek Martin wrote:
> On Sun, Mar 18, 2007 at 08:44:44AM +0000, Dave wrote:
> 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.
I don't lose patience with threads. If I'm going to make an argument, you can
bet that I won't waste your time writing a reply that I won't read.
> > 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.
Look, if the user doesn't care, that's his own choice. We're programmers, not
policemen. If you want to force the user to follow your rules because you think
you have the right to not trust a user with his own system, get Palladium, or
whatever MS renamed it to. You're setting a dangerous precedent by assuming
that your users are stupid. UNIX isn't for stupid users to begin with, but a
stupid user who chooses to use a free (free as in freedom) system takes on
exactly the same responsibilities as a smart user who chooses to use one. There
is no reason to handicap a smart user's system just so you can handicap a stupid
user's system "for his own good." Your logic here is screwey, because we _must_
assume that the user has enough of a clue to care about whatever he wants to
care about. We have no right to dictate what users must care about. Each user
decides by action or inaction what he cares about, and we have no right to
invade his decision space.
> The problem
> with that assumption is, as I've already said, and everyone here
> already knows, most users don't.
So be it. Again, our job isn't to create policy, just to follow existing ones.
> 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.
It can be as malicious as it wants to be. Sound programming design eliminates
most opportunities for malicious data to break the program itself, and stuff
outside the program itself (such as the locations of other programs) isn't our
responsibility to protect. If the user doesn't care enough about his $PATH to
protect it, we have no right to break system functionality in order to protect
him from his own decisions. We're not in MS-land here: You have every right to
shoot yourself in the foot, and we have no right to stand in your way. Our only
responsibility is to make sure that the programs we write don't have bugs. If
everybody can live up to that simple responsibility, we have a perfectly secure
system. Ah, but we can't possibly live up to our responsibility, you say. In
that case, you should spend your energy on an audit of your own program, not on
setting up minefields for your users on their own systems in the hopes that you
might happen to also catch some malware off-guard.
> If only the user were affected, that would be one thing.
If your security is compromised by the actions of another user on his own
system, then your security model is screwed up.
> 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.
FUD
> 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.
In that case, don't give users root access to their own computers. After all,
the whole universe might collapse if they rm -rf /. Again, the security of your
system should not depend on the security of my system, and _certainly_ shouldn't
depend on the security of a system owned by an "ignorant user."
> Mutt can't afford to trust that the user will get his own security
> right,
Fortunately, Mutt doesn't have the right (and certainly not the responsibility)
to mistrust its own user. The user is the boss; Mutt is the user's slave.
Mutt's job is to do what the user wants, not what Mutt thinks the user _should_
want.
> because in the overwhelming majority of cases, it just won't
> happen,
So be it. A user has every right in the world to run an insecure system.
> and the user is potentially far from the only one affected
> when it goes wrong.
Again, you shouldn't tie your own security to the security of a user who can't
get his own security right.
> Most of us remember when e-mail worms took down
> whole companies, and maybe even worked at one of those companies.
What took down companies was generally just the sheer volume of mail passing
through their servers. Standard DDoS protections could've been used.
> You
> probably know someone who had their company directory stolen via such
> a bug. This stuff is NOT trivial.
If you're a company and your company directory is top secret, why are you
trusting its secrecy to somebody else's system?
If you're referring to a company-owned computer being compromised, the company
is the boss. If the company is too stupid to hire a consultant, it deserves
what it gets.
Throwing away the owner's bill of rights because some people are idiots makes no
sense whatsoever. Even if every single human were an idiot, that wouldn't in
any way, shape, or form, give you the right to take away their free choice in
the matter of their own system.
> > 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.
It's always the correct solution. Obviously, a program with easily-overflowable
buffers isn't living up to the UNIX philosophy (picking one job and doing it
right - if you're full of bugs, you're not doing your job right).
> The Unix Philosophy sired a great
> many programs that were security abominations.
Interestingly, most of the programs that spring to mind when you search for
security vulnerabilities on the UNIX platform are actually poor candidates for
their jobs. A monolithic email server like Sendmail, for example, is trying to
do way too much in one program. If you look at the qmail system, you'll see a
far better solution to the problem - many individual programs with individual,
well-defined jobs.
> 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
Pay special attention to the "Flexibility All the Way Down" section, in
particular:
Unix tradition lays heavy emphasis on keeping programming interfaces
relatively small, clean, and orthogonal -- another trait that produces
flexibility in depth. Throughout a Unix system, easy things are easy
and hard things are at least possible.
That's why UNIX provides $PATH. Individual programs should not reinvent the
wheel of program finding. They should not set up parallel (nonorthogonal)
interfaces for specifying program locations. Changing the paths that a program
scans for other programs should be the same for any program:
PATH=/my/favorite/bin mutt
or
PATH=/my/favorite/bin elm
or
PATH=/my/favorite/bin bash
I showed some cases (in the sendmail thread) where easy things become hard
because of mutt's sabotage of UNIX's small, clean, orthogonal interfaces (just
in case anybody thinks my arguments are purely theoretical).
> > It's not Mutt's place to refuse to honor my $PATH just because IT
> > doesn't trust it.
>
> Sure it is.
We have a fundamental disagreement about the ownership of a computer system,
then. By my view, all decision-making in a computer is owned by the computer's
owner, and may only be delegated to programs voluntarily and explicitely. If I
order Mutt to run gpg, it has a responsibility to run gpg, using the standard
UNIX conventions for running "gpg." Any other behavior if accidental is a bug,
and if deliberate, is just plain wrong.
> If Mutt can help the user get it right by enforcing
> minimally restrictive measures, how is that a bad thing?
"Getting it right" is a subjective term. "Minimally restrictive" is also a
subjective term. That's why I proposed giving the user an option to voluntarily
restrict himself in a way that statistically may be acceptable to him.
> I could
> point you at numerous papers and books recommending against
> security-sensitive applications trusting the user's PATH,
I can, too. You can't point me at any UNIX-compatible papers or books
recommending against trusting the user's $PATH, though. The reason is that any
such paper or book is by definition violating the UNIX philosophy. I definitely
agree that a user should seriously consider instructing his programs to ignore
$PATH under certain circumstances if he wants an extra security net, but that's
my recommendation to a user. We have no right to default to such a policy,
since it's not UNIX-compatible.
> but I won't
> bother...
Thank you for not wasting our time with something immaterial to the discussion
at hand.
> you won't read them anyway, and if you really wanted to you
> could find them easily enough by searching your favorite search
> engine.
...and, as I mentioned before, I don't doubt that the papers/books you mention
exist, but since they're not UNIX-compatible, they're irrelevant
> 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
I take back my "Thank you" above.
> Ooh, what's that you say, Peter?
This:
10. Distrust the unknown. Anything provided by users or from outside
of the program is suspect.
His error is that he neglects to draw the distinction between user input and
"outside" input. User input should only be validated as far as necessary in
order to satisfy preconditions for functions that said input is used in (i.e.,
only as far as necessary to ensure that we don't overflow a buffer, etc.). Only
"outside" input should be scrutinized more than minimally necessary, and even
that only at the user's request.
> E-mail applications should not trust
> the user's PATH? Hmmm... Convenient that he named that example
> explicitly.
That's just a symptom of the problem I noted above.
> You don't believe me that Peter Galvin is a renowned
> security expert? Search Google for "Peter Galvin security" -- that
> should convince you.
I don't doubt that he's a security expert. I doubt that he's a UNIX expert, and
I support my doubt with the evidence you just brought, showing quite clearly
that he has no interest in being UNIX-compatible.
> > If I trust it, what's Mutt's problem???
>
> If you have no clue, your trust is worthless.
If I'm the owner, my trust is the only thing that matters in my system.
> When we design the
> security of our applications, we have to assume that the user is
> completely clueless, because mostly they are.
There's a term for such a method: It's called Design by Democracy.
> If you can specify the
> full path to your GPG installation, I really don't see what the big
> deal is.
I shouldn't have to, in a UNIX-compatible system. If I have to, my system isn't
UNIX-compatble.
> 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.
There's no reason I can think of off-hand for somebody not to build an
almost-UNIX-compatible OS for clueless users who don't like Windows for whatever
reason. If there's demand for such a system, it'll sell. There is a reason I
can think of off-hand for not hardcoding Mutt for the clueless user
not-quite-UNIX-compatible system: We UNIX users also want to use Mutt.
Of course, if you really wanted to follow the UNIX philosophy _and_ take care of
clueless users, the correct solution would be to ask the system if the user
considers himself clueless, and to act on that basis. In other words, a
UNIX-compatible system that wanted to give clueless users an easy way to
delegate many decisions to the system could ask the user during installation
"Are you a clueless user who'd like me to limit your flexibility in an attempt
to bolster your system's security?" If the user answered affirmatively, the
system could then signal Mutt (by, say, /etc/user-is-clueless) to honor the
user's wishes, and disregard $PATH.
> I can't see any sane argument for this being bad.
I can't see any sane argument for taking away users' freedom without their
consent being good.
> Searching for applications via the PATH in a security-sensitive
> context is, was, and always will be a potential source of security
> problems.
...as is turning on a computer ... yet my computer doesn't refuse to turn itself
on ;-)
> 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.
I don't necessarily disagree with that.
> You could argue
> that such a small difference makes it not worth losing a little
> flexibility,
Your error is that you're attempting to weigh security against freedom. Users
have the UNIX-given right to absolute freedom with their own systems. If
potential security (it's only potential, since we can easily prove that the UNIX
philosophy produces a fully secure system if implemented right) must be
sacrificed, then so be it. Benjamin Franklin's famous quote comes to mind here,
although it's totally irrelevant, AFAICT ;-)
> 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.
Again, you're looking at program design as a compromise between security and
flexibility. That's not the UNIX philosophy. The UNIX philosophy says you
don't need to compromise, because you can have the best of all worlds. (An
interesting side-effect of the UNIX philosophy is that you're often only one
vulnerability removed from a potentially exploitable security hole. The UNIX
philosophy isn't meant to shield you without your consent from the consequences
of misplacing your trust in a buggy program, though. User security is the
responsibility of the user. He can delegate much of it to the system, but the
system has no authority to steal any of it from the user.)
> Taking this seriously has virtually no negative impact on the user:
I'd consider the sendmail fiasco as having a negative impact on the user. Also,
any program that forces me to learn a new way to tell it where to find gpg (a
"more secure than UNIX" way) likewise has a negative impact on the user.
> configure it once, however you chose to do so, and be done with it.
I shouldn't have to configure a program manually just because it refuses to be
compatible with my OS. ESR clearly agrees with me.
> Mutt already has a zillion things that MUST be configured when you
> start using it,
FYI - When I started using Mutt again after my server's mobo went (without any
of my old config, which many of you may recall, was quite substantial), I didn't
have a .muttrc for a while. Mutt worked fine. Clearly, "MUST" is a subjective
term.
> so one more is totally negligible.
Going from zero mandatory configs to one mandatory config isn't at all
negligable, but we're missing the point: there's no reason why I should have to
configure Mutt separately from the rest of my system - and now, here's the
kicker - for a mechanism that my OS has been providing for longer than Mutt's
even existed. Mutt is simply introducing bloat into the system, by providing a
new, nonorthogonal interface.
> 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.
There you go again, with your compromises. You also incorrectly assume that
that's the only downside of replacing the UNIX $PATH functionality with a (far
inferior) config file syntax. You also lose the capability of changing the
location of gpg from the command line without doing even more manual
configuration using the config file syntax. If we think for a short moment, we
can come up with many more complicated tasks that become downright infeasible
with your "secure" replacement for part of my OS. Remember what ESR said, about
easy tasks being easy in UNIX, and hard tasks at least being possible? We have
easy tasks here becoming quite complex ... which should come as no surprise,
given the fact that we're violating the UNIX philosophy.
> The conclusion is that some kind of PATH protection should be
> included.
I don't know about THE conclusion, but my conclusion is that some kind of
$PATHological disregard should not happen without the user's specific request.
If you want to offer the user an option to disregard his $PATH (since after all,
our security expert recommends that users may want to instruct their email
programs to do so), I'm all for options. However, default behavior should
always be compatible with UNIX, rather than going out of its way to not be.
> I favor compile-time hardcoded path, which can be specified
> by configure option, and overridden in the config file by specifying a
> full path.
Needless to say, I don't.
> I'd also really like to see a configure option for mutt
> refuse to run binaries in directories where the user has write access,
I think that's a useful option.
> enabled by default, but whatever.
Again, it shouldn't be enabled by default, unless the user has already informed
his OS that he'd like the system to go out of its way to protect him. (Such a
flag might also signal rm(1) to do -i by default, for example.)
> If you want or need this level of
> security, there's no reason it shouldn't be available.
I fully agree.
> Some of it's
> already in mutt, and the rest is not difficult to include.
Unfortunately, we've seen that much of it is hardcoded into Mutt, without even
the option of being UNIX-compatible :-(
> > 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.
There are at least three problems with your method:
1) The user can't do "^Zvi .mutt/gpg.rc" from Mutt.
2) The user may not know the significance of "gpg.rc has been modified," and so
may not be safe, even with your UNIX-incompatible proposal.
3) If malware modifies .mutt/gpg.rc when Mutt isn't running (since it's an easy
target), how does Mutt know that there's been a change? Should we store MD5s
between sessions? What then happens when a user modifies gpg.rc, and doesn't
bother to run Mutt again for a few days? Does he get a false alarm that he
can't associate with the modification he made a while ago? How about if our
malware deletes the md5s.data file, or finds some way of replacing it with a new
version that correctly accounts for the new gpg.rc?
> That should go in too, ideally.
If you tune your idea, you can turn it into a useful program. (Remember, UNIX
says you should do one thing and do it well. How about tracking config files
with GIT or something?)
> It wouldn't affect the user AT ALL, but it would make them safer.
Whatever. . .
> > 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.
I was inaccurate above. "The subject" is the security implications of $PATH in
a UNIX system. Your expert isn't an expert in the subject at hand. I can also
bring in Gary Kasperov and ask him for a recommendation about whether or not to
follow $PATH in email programs.
> Where's yours?
I don't usually bring experts to discussions. If they don't like something I
say, they can pipe up and complain. That said, one of your experts could just
as easily have been mine: ESR is a known, verifiable expert in many fields
surrounding UNIX, and he's not a dope when it comes to security.
> 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.
I seriously doubt you'll find any real chess expert who will advocate
sacrificing a king for a pawn, but what's good advice in one domain may very
well be incompatible with another domain. Such is the case here. While the
security experts know that being two vulnerabilities removed from a security
hole is safer than being only one removed in the real world (although again,
it's trivial to show that UNIX is perfectly secure if implemented right, so the
concept of "more secure than perfectly secure" is a tad hard to wrap one's brain
around), violating the UNIX philosophy is an unacceptable sacrifice, since it
renders the system UNIX-incompatible.
> > 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?
Gee, I don't know the chapter and verse off-hand. If you feel like emailing me
the specs, I'll do a quick search for you.
> > who the hell are we to deliberately break compatibility???)
>
> We are the people who know better... ;-)
...and therefore, we must steal the user's control over his own computer. . .
> I conceed that I'm not an
> "expert"
I don't judge what you say by who you are (at least not consciously). I don't
assume you're wrong if you tell me that 1+1==2, even if you're not a Mathematics
expert.
> (a word which is much overused, I think)
agreed
> 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.
I don't doubt that you know a thing or two about security. My issue is with
your UNIX philosophy knowledge.
> --
> This message is posted from an invalid address. Replying to it will result in
> undeliverable mail. Sorry for the inconvenience. Thank the spammers.
This message is posted from a valid address. Replying to it will result in
deliverable mail to a real person. Thank the SPAM filters.
- Dave