Re: [PATCH] Remove absolute paths from gpg.rc
On Tue, Mar 20, 2007 at 12:14:17PM +0100, Oswald Buddenhagen wrote:
> On Tue, Mar 20, 2007 at 07:28:36AM +0000, Dave wrote:
> > On Mon, Mar 19, 2007 at 11:51:37PM -0400, Derek Martin wrote:
> > > 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.
> >
> it sort of defeats ~/bin.
Well, you can "lock" ~/bin by chmod(1)ing u+w ~/bin before every time you add or
remove a local script/program, and u-w after you're done.
> the most secure solution is already the default: no sane program (except
> the linker) creates/saves files with an executable bit set. this is a
> conscious decision of the user - at the point where it is not, the
> security was already compromised.
I don't disagree with your last statement. However, some people may appreciate
the added bit of security gained by extra restrictions on program execution.
> > > 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.)
> >
> this "user is [security wise] clueless" flag sounds a lot like the
> concept of user expertize levels in general. a lot has been said why
> this is a bad idea. check the kde-usability@xxxxxxxxxxxxx archive.
I don't necessarily believe that user expertise levels are a good idea. My
proposal is to ask the user at system installation time whether the system has
permission from the user to make certain types of decisions on the user's
behalf. The only purpose of that proposal is to allow security-conscious
programs to automatically protect stupid users who are interested in that type
of protection. A system wouldn't be required to ask the user for said
permission at installation (so, for example, Slackware would almost certainly
steer clear of that qusetion), but a system targetted primarily at cluless users
would probably be doing its users a favor by asking such a question at
installation time. The nice thing about the UNIX philosophy is that it doesn't
preclude systems from offering innovative functionality targetted at particular
types of users. It only requires that the default behavior not trample the
user's freedom of choice.
> derek's approach is counterproductive: users will always invent creative
> ways of compromising security, and are even more motivated to do so if
> the system behaves non-predictably (unix incompatible, as you say it).
You're basically giving one of the indications supporting my assertion that the
UNIX philosophy is the only way to compute that makes any sense.
> otoh, most users *are* idiots (yes, even the unix users -
Idiots have the right (a) to exist, and (b) not to have decisions that are
rightfully theirs stolen by a zealous system, not even in the name of security.
People don't lose their rights by being idiots.
> most corporate
> users don't choose their environment,
You've been confused by our two uses of the term "user" in the discussion. When
we talk about the user of a system, it's the corporation itself (the "guy" who
bought the computer in the first place). The guy who sits at the keyboard and
physically computes is just an agent of the "user." If the corporation decides
to delegate certain decisions to the system in the interests of security, an
employee of said corporation must honor the corporate decision. (Otherwise, our
"user" has a split personality, and the system can't possibly hope to figure out
what the heck he really wants.)
> and the raising numbers of private
> linux users doesn't exactly help, either),
For them, there's a system-installation-time question allowing them to delegate
security-related decisions to the system.
> and even the most security
> conscious ones make mistakes.
It's up to an individual user to decide not to trust himself, if he knows he's
in the habit of making mistakes. The system has no right to assume that the
user doesn't trust himself. (That's the Microsoft philosophy, not the UNIX
philosophy. Actually, I think the Microsoft philosophy is something along the
lines of this: The user is just a user; his only right is to pay.)
> when weighting the convenience of the
> users against the future of a company and possibly thousands of
> secondary victims, the decision is pretty clear.
That's a business decision of a company, that it may make for its own systems
(i.e., the ones that it's the user of). Obviously, it has no authority to make
such a decision for its employees' personal systems, and certainly not for every
Mutt user on the planet!
> if there only wasn't
> the previous paragraph ...
You view the problem with Derek's approach in a purely practical way, and so
your solution is to try to find a way around the problem. I view Derek's
approach as fundamentally wrong, since it violates user rights. That's why I
don't even try to get around the "problem."
> so the key is to design security in a way that does not get in the way
> of the users, so they don't try to work around it.
As I said, your approach is to try to get around the "problem." To me, the key
is to stick to the UNIX philosophy: to build small programs that pick one thing,
and do it right.
> an essential part of
> that design is educating the users, btw. wow, that's what i call stating
> the obvious.
The only education a user needs is an introduction to the UNIX system, so he can
understand the structure of his system, and make informed decisions. It's the
user's responsibility to either educate himself or delegate decisions to others,
but it's not our responsibility (or right) to enforce it. If I buy a radio
control car, the car has no right to refuse to drive off the edge of my roof.
(Incidentally, once you change to a real car, we open a whole new can of worms,
since we bring in [OT] the ethical question of what your children's status is.)
> so ...
> regarding the umask i can only say that i never liked it - it's way too
> broad and it always gets in the way. i determine default permissions by
> putting stuff in the right directory ...
To each his own. Mutt's responsibility is not to steal any decisions from you.
> regarding the paths, i'm strictly against hard-coding anything in
> the binary.
I'm strictly against hard-coding paths anywhere, since providing paths isn't
part of Mutt's job description. That's part of the job of the underlying
operating system.
If gpg poisoning worries you, replace execvp(2) with a wrapper that doesn't
search $PATH for gpg, opting instead for a hash lookup or something to find the
full path to the binary.
> i can accept absolute paths determined at configure time in
> the default config,
I can't. The configure script has no authority to steal decisions from the
user. The user owns his copy of Mutt, not the other way around.
> but i don't think it is an advantage of any kind.
I don't, either.
- Dave