Re: [PATCH] Remove absolute paths from gpg.rc
On Tue, Mar 20, 2007 at 09:00:00PM -0400, Derek Martin wrote:
> On Tue, Mar 20, 2007 at 07:28:36AM +0000, Dave wrote:
> > 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.
>
> This is complete and utter nonsense.
>
> I'm guessing you're like a 2nd or 3rd year college student, idealistic
> and optimistic about future possibilities, excited about a career
> working with Unix.
Your guess is off the mark, but it's irrelevant.
> And naive as all hell.
That may be so, but I'd counter that you're naive for thinking that disobeying
the user will earn you security.
> Programmers didn't need to
> be policemen in 1968 when Dennis Ritchie and Ken Thompson were working
> on Unix... there were about 3 people using it back then.
...which would explain why the original UNIX system didn't bother to protect
users from malicious users
> Today things
> are different; programmers ARE and MUST BE policemen, because the vast
> majority of users don't know any better.
You're actually assigning programmers not only the role of policemen, but also
the role of courts, giving them the power to deprive users of their own free
choice. I'd consider your argument 100% bogus. As I said, users have the right
to decide whatever they want, out of knowledge or lack thereof. If it's their
system, it's their decision, by definition. Anything else is stealing.
> Everything you've said in
> this message has proven beyond a shadow of a doubt that you are one of
> them.
one of the programmers? fine
one of the policemen? God, no!
one of the users who don't know any better? if you say so
> > 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.
>
> Wrong again. We must care about security, because USERS WANT US TO.
You have no right to assume that users want to give up their free choice to you,
nor to anybody else. If a user tells you (through a clean, simple interface
exported by the system) that he wants to give up his free choice in exchange for
your promise of better security, that's a decision he's free to make or not
make, but you have no right to force that decision on him.
> They want security, but they don't want to have to learn about it.
As DMR pointed out, most security problems in modern UNIX systems have to do
with the user simply not really caring much about security (which would seem to
call your SHOUTING comment above into question). The correct solution is for
users to learn about it. If they don't want to, their security is going to
suffer anyway. We can offer them the option of trusting us to make decisions
for them, but we can't force that option on them.
> Users made it our job.
Correction: Certain users made it our job. Those certain users have no right to
take free choice away from the rest of us. Rights don't disappear just because
a population Democratically votes to surrender them. Ten million users can
decide to give up their rights, but if one doesn't, we have no right to take his
rights. You assign too much power to Democracy.
> > > 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.
>
> Here's where you proved beyond a shadow of a doubt that you don't know
> anything at all about what security is, or how it works.
I'd like you to explain how a sane security model for your system can allow my
system to compromise your system. If you can do so, I'll accept that I don't
know anything at all about what security is, or how it works.
> > 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.
>
> You have the audacity to cite "errors" in the advice of one of the
> most renowned and respected computer security experts in the business.
> Unbelievable!
Maybe your problem is that you expect security experts to be user rights
experts.
> > If I'm the owner, my trust is the only thing that matters in my system.
>
> And who will you blame if your system gets compromised? The
> programmers...
If my system is compromised because a program didn't pick one thing and do it
right, that's the programmer's fault, and he deserves all the blame. If my
system is compromised because I configured it in an insecure way, that's my own
fault.
> The rest of what you wrote is simply too naive and in some cases
> asinine to respond to.
Nobody forces you to respond to any of what I say. I'd take issue with your
libel, though.
> Blind adherence to any philosophy or dogma is
> folly, and your blind adherence to the Unix philosophy is your folly.
My blind adherence to the philosophy that says that I have full rights over
anything I own and no rights over anything I don't is easily proveable to be a
legit way of creating a fair system (a fair system by definition has no security
vulnerabilities, since any such vulnerability would render the system unfair by
allowing a user to steal rights from another), if you assume that everything is
owned by somebody. (Obviously, the networks connecting our computers aren't
owned by either of us, but we can treat the networks as air carrying sounds for
purposes of evaluating security between interconnected systems.)
> No philosophy is always right.
A philosophy that isn't always right isn't a very well-thought-out philosophy,
now, is it?
> Your ravings about manipulating $PATH
> being incompatible with Unix are absurd in the extreme;
The specs say that you're supposed to use $PATH to find other programs, if
you're a program. Besides, the UNIX philosophy says you should use $PATH
because it's the only convention exported by the system for that purpose. (I
suppose you could create a new system with a different method for finding
programs, but it wouldn't be UNIX.)
> this is an
> established best practice for security-sensitive *UNIX* software for
> more than a decade.
Just because the software appears to run on UNIX (or is marketed for UNIX, for
that matter) doesn't mean it's UNIX-compatible. Remember, UNIX-compatible
software sticks to the UNIX philosophy, which requires using the small, clean,
orthogonal interfaces exported by the system, like $PATH, rather than
reinventing the wheel at every opportunity.
> Your blessed qmail
I don't recall "blessing" qmail, although I consider it a very fine piece of
(not necessarily UNIX-compatible) software. Understanding DJB is sometimes
tricky, so I don't hold him to the same rules of respecting user freedom, but I
also don't blindly trust his systems to respect my freedom. I read the
documentation, think a bunch about all my questions, read the source to answer
my questions, and then decide whether I'm interested in giving up the freedoms
he's asking me to give up before installing. My decision to use qmail wasn't
an easy one, but it's paid off in gold over the years.
> uses it (it inserts its
> installation directory first into the PATH, to ensure that any
> programs it calls are the right ones),
I know. It also had some absolute paths last I checked. However, qmail is one
of the best MTAs out there at following the UNIX philosophy of picking one
thing, and doing it well. (The alert among you will notice that we've been
calling two different things "the UNIX philosophy." The UNIX philosophy is a
belief system about how the world should work, and DMR explains it fairly well
in a number of essays. He misses many of the fundamental points about user
rights, though, since his goal in creating UNIX had nothing to do with user
rights, and everything to do with creating an efficient system for his company
to use. He also has the interesting habit of self belittlement, which makes him
a tad hard to quote. At any rate, we're getting off-topic.)
> as does any sane
> security-sensitive application.
...but not a sane security-sensitive UNIX-compatible application
> "The first fact to face is that UNIX was not developed with
> security, in any realistic sense, in mind; this fact alone
> guarantees a vast number of holes."
The second fact to face is that while UNIX wasn't originally developed with real
security in mind, security came quickly, and fit into the clean interface very
neatly. (Nearly all the shortcomings that DMR enumerates in that essay have
been solved in a clean way since then, for example.) The advantage of a clean
system design is that when you create a new security feature, it can instantly
be applied to the entire system, since everybody uses common interfaces. The
disadvantage of having every program decide for itself how to execute a binary
is that if the system adds a new feature to secure executables, Mutt security
suffers because it violated the UNIX philosophies of picking one thing (not two)
and doing it well, and of using simple, clean, orthogonal interfaces exported by
the system (execvp(2), for example).
> --Denis Ritchie, designer of Unix and creator of the Unix
> Philosophy
creator of part of the UNIX philosophy ... for the rest, look to RMS, although,
ironically, GNU is really Not UNIX ... RMS gives the user too many obligatory
choices ("Do you want save before quitting?"), rather than taking the user's
word for what he wants at face value
>
> http://scholar.google.com/scholar?hl=en&lr=&q=cache:8DMaAOIZSQkJ:secur.ibelgique.com/unix/ritchie.ps+
That's an instructive essay. It shows the ease of creating a secure system,
starting out with nothing but clean interfaces.
- Dave