Re: [PATCH] Remove absolute paths from gpg.rc
On Thu, Mar 22, 2007 at 08:45:20PM -0400, Derek Martin wrote:
> On Thu, Mar 22, 2007 at 04:34:44PM +0000, Dave wrote:
> > I've already explained several times that the user doesn't own the
> > system. The physical user is governed by the owner of the system.
>
> This view also completely overlooks the plain fact that Unix is
> inherently a multi-user system, designed from the start to be used
> concurrently by multiple users, each of whom has a different usage
> model.
A multi-user system simply means a system that's designed to make it easy for
the owner to share access with multiple other (possibly untrusted) users. There
is still only one owner, and he's responsible for setting policy for his system.
> It is still very often used that way, at Universities,
> research facilities, or even businesses where a server provides shared
> resources to a multitude of users, possibly in more than one way.
The owner in each of these cases, respectively, would be the university, the
research facility (acting as an agent of the parent company), or the business.
> There may not even be any one designated system administrator; all
> users may share the system, and responsibilities of maintaining the
> system, equally.
All the users who are given the root password are sysadmins, that is agents of
the partnership that owns the system.
> In such cases, their personal security practices
> absolutely can impact all of the other users.
A sysadmin is in charge of administering the system. If he allows somebody else
to do his job for him without a proper background check (whether by giving him
the root password, or by leaving a security hole that allows somebody else to
take over the system), he's obviously not doing his job so well, now, is he?
If you don't trust the sysadmin of your local communal server, don't use the
server. If you don't have a choice, then you're in the same position as an
Iraqui citizen.
> Mutt runs on such
> systems.
That's a good thing. Mutt runs practically anywhere, unlike smart programs (you
know, like Outlook or Thunderbird - the ones that insist on confirming every
other action you attempt to take).
> In such an environment, or in any environment, all three components of
> the system, the users, the administrator(s), and the software, play an
> important role in maintaining the security of the system. They must
> work together.
That's how Windows works. If you have a weakness in any of the above, the
system security is effectively compromised.
In a UNIX-compatible system, though, the sysadmin is generally the only one of
your big three responsible for securing the system itself. A user can install
and run any software he wants, but the system will protect itself from both the
user himself and the software he runs (which are identical, as far as the system
is concerned - yet another example of security by simplicity).
> The security administrator's role is to assess the
> level of risk associated with each computing resource, and determine
> what policies for access and what protections should be put in place
> to safeguard the resource, while still allowing the users to
> accomplish their goals and fulfill the requirements of their roles.
That's a lot of verbage for a simple job: His job is to make sure that the
system is administered properly. That means auditing system software, and then
installing it in a secure way. It can also mean installing copies of user
applications, but it doesn't have to. Users are responsible for their own
software, unless the sysadmin wants to take that responsibility to himself.
Again, as an agent of the owner, the sysadmin makes policy, in whichever way he
sees fit. If he doesn't represent the interests of the owner, the owner will
toss him.
> The user's job is to adhere to the security policy and dilligently
> protect all accessible computing resources,
That's junk: The user's job is to get work done using the system. That's where
his job begins and ends.
> so that their exposure
> does not harm the user,
A user is entitled to harm himself.
> the system,
If a user account gone bad harms the system, the sysadmin isn't doing his job.
> or the organization on whose
> behalf the user is working, if there is one.
That's a matter between the organization and the user to work out.
> It is the role of
> software, first to work properly in order to aid the user in some
> task, and secondly to do so in a manner which will safely prevent
> other users from leveraging that program to gain unauthorized access
> to any computing resource, or to the user's own data.
A program's only job is to pick a job and do it right. If the job the software
does is murkey (say, send and receive email, and allow people to overflow
buffers for fun), the software in question probably shouldn't be used.
> In order to do
> this, it MUST avoid a wide variety of pitfalls which the average user,
> and indeed even computer savvy users, simply are not aware of.
In order to do this, it must simply do its job right.
> These
> pitfalls include insecure temp file creation,
There's only one program that should be creating temp files, a program designed
for that purpose. It's the user's responsibility to configure said program.
Obviously, the program should simply apply the user's umask by default.
> symlink attacks,
The sysadmin can avoid symlink attacks by configuring the system right.
> inadequate default protections on newly created user data files,
Again, umask solves our problem in a clean, simple, orthogonal way.
> sanitizing the user's environment to prevent unexpected/undesirable
> behavior,
Trashing a user's environment is the job of only one program, one built
specifically for that purpose. Such a program falls under the category of
malware. It goes without saying that such a program probably shouldn't be used
much.
> careless use of relative paths,
It's the user's responsibility to give a program correct inputs. If something
gets lost in the translation from English, the user needs to go back to class,
or the programmer needs to simplify the program (not to make it more complex,
and to try hiding even more complexity).
> a wide variety of
> vulnerabilities related to SUID binaries, if such are needed,
If a user wants to create a SUID binary, that's his own choice, and he'll have
to live with the consequences.
> and many
> more than I could hope to discuss in this thread.
Gee, it sounds like the system is doomed from the start, with your approach.
You can't even give me the job of the programmer in a whole email. I gave it
all in one sentence.
> Whether or not YOU think so, whether or not YOU want it, programs MUST
> do this.
...of course, because YOU say so ;-P
> It IS the role of the programmer to provide these
> protections, because the simple fact is the majority of users want it,
> expect it, and DEMAND it. And cry foul when you fail to do so.
I see, a programmer is also a politician. Why didn't I think of that earlier?
> Maybe YOU don't want that... but you are the exception, and no
> programmer should design his code around what is desired by fringe
> users.
Nope, a programmer should never design his program right, since only other
programmers will use it, and the world will fall apart if that happens. That's
ridiculous: Mutt was designed by fringe users for fringe users who want an email
program that sucks less. Democracy sucks more, not less.
> In an earlier thread, you said something to the effect that
> programmers do not have the right to take away freedoms to provide
> security.
That's almost correct. (I talked about rights, and the freedom to enjoy said
rights.)
> This displays a fundamental and egregious lack of
> understanding of what security is, as indeed that is exactly what
> security is. The defining essence of security is precisely to take
> away freedoms from a group of individuals in order to safeguard
> something of value.
The "something of value" here is the ability to get work done efficiently using
the system. (I'm just making sure we're on the same wavelength, here.)
Let's analyze the freedoms we must take and the groups we must take them from:
sysadmin => none
system users => the ability to play with other users' private stuff
aliens => the ability to prevent users from getting work done efficiently
Now, the OS takes care of the sysadmin's limits and the system users' limits.
It also takes care of preventing aliens from invading the sysadmin's account,
assuming the sysadmin knows what he's doing. Preventing aliens from invading
user accounts is a matter between the user, the sysadmin, and the alien, to
settle among themselves.
> If I put locks on my door, I take away your freedom to enter my home
> freely, in order to safeguard my personal belongings.
There's no reason not to put a lock on your door, and there's no reason not to
put a password on your account (if nothing else). You're not taking away from
me any rights that I had before. (Remember, I never had the right to enter your
home, even before you got the lock. Your lock is the equivalent of a police
force: it assists you in preventing me from violating your right to enjoy your
own home.)
> If I put a
> fence around my house, I am restricting (though perhaps not
> preventing) your ability to enter my yard, to prevent you from
> damaging my property or attacking my home.
Again, a fence is nothing more than a password, a.k.a. a border patrol.
> If I set permissions on my
> files so that only I can read them, I am taking away your freedom to
> read them, in order to protect the contents from people who should not
> be able to read them.
Again, you're not taking away any rights I had before. Setting up watchtowers
on your side of the border is always okay. You have the right to enjoy your
system, and the freedom to protect it.
> The situation is less clear for e-Mail though; my personal security
> policy does not simply protect my own privacy. It also protects the
> privacy of anyone who sends mail to me.
First of all, privacy and security aren't the same thing.
> People have a right to expect
> that if they send you mail in confidence, you will respect that
> confidence.
Second of all, you have no right to restrict my free speech. If you'd like me
to sign a contract to protect your privacy before you'll agree to mail me,
that's your own choice. Absent an agreement to the contrary, though, you have
no right to prevent me from using my right to communicate anything I want to
anybody I want. Information isn't property.
> It is not fair to people who send mail to you for you to
> make a decision, as a matter of policy, that you will not respect
> their privacy.
First of all, it is fair. It's 100% unfair for you to expect me to keep
anything you say secret. You don't own what you say. Anything I hear,
regardless of how I hear it, becomes part of my information base. It's my right
to do anything I want with my information base, as long as I don't violate other
people's rights. (No, you have no right to have your information kept secret.)
That said, there may be social reasons not to take advantage of your right to
broadcast anything you hear; if people get used to seeing everything you hear on
the front page the next morning, don't be surprised if they start signing
agreements with each other to not tell you things.
> By setting the umask to 077, Mutt helps you not just
> to protect your own privacy, but also to protect the privacy of other
> people who send you mail with the expectation that you will safeguard
> their privacy.
This is a classic case where identification of a nonexistant right of one
prompts flagrant trampling of a very real right of another.
> In so doing, Mutt rightly prevents you from
> disregarding other people's privacy as a matter of policy, and forces
> you to make a concious decision to perform a malicious act of
> violating their privacy.
Mutt's behavior is malicious by definition, since it refuses to honor its user's
wishes by default. (A virus is malicious for the same reason: it does what _it_
wants, not what _you_ want it to do. Even a harmless virus is still called a
virus, because it still _is_ one.)
> The very same goes for attachments,
> temporary files, or any other file that Mutt creates which is related
> to your mail.
Okay, let's create a whole DMCA around our copyright system. We must protect
nonexistant rights at all costs.
> Your security does unquestionably impact the security of others, all
> the time, without you thinking about it or being aware of it.
Again, if my security impacts your security in any tangible way, I'd be very
scared to be one of your users, regardless of your job title.
> On
> behalf of those others, Mutt can not and must not trust you to get it
> right.
If your programs do what other people want them to do, in flagrant violation of
what you want them to do, I can see why my security impacts yours.
> What you do after Mutt creates a copy of the data is not
> Mutt's purview, so if you decide to be a malicious jackass and make
> someone else's private and sensitive e-mail publicly available for
> anyone to read off your NFS mounted home directory, Mutt's developers
> can rest easy knowing that they had no hand in that.
I hate to disturb their rest, but they could always trick the sysadmin into
installing a rootkit implementing DRM. After all, this is others' security
we're talking about, here. _Your_ Mutt must protect _their_ security. . .
> As for the case of absolute paths: the case is harder to make, and
> I've no doubt that YOU will be unconvinced, but it is a makeable case.
I'm listening.
> In many places, computers are shared resources, and often groups are
> collaborating. It may be that as a matter of policy, the programs
> being developed by the group must go into a directory writable by the
> group.
Security experts everywhere might flag that as an insecure policy.
> A malicious user -- perhaps someone intent upon stealing a
> coworker's research --
Wait a minute, you're scared of people stealing your research, and you've got
an insecure policy? Who's the nutcase who made _that_ "a matter of policy?"
> could insert a trojaned copy of gpg which works
> correctly for everyone except the target user, into the shared
> directory.
Now, you know why it's an insecure policy. A user running gpg from the command
line would fall into the same trap. Boobietrapping Mutt doesn't boobietrap the
entire system. You'll need to nuke execvp(2) in bash, tcsh, and whatever other
shells are used in your system, if you want to try protecting your system
against such an insecure policy. Your other option, of course, is to replace
the buggy policy with a more secure one - say, having root-owned symlinks to all
system utilities in that shared binary directory.
> Like it or not, Mutt runs on such systems.
Mutt runs on many poorly thought out systems. Fixing faulty systems isn't
Mutt's purview.
> Mutt should not use the user's $PATH to find GPG (or any binary),
> because:
>
> 1. Not all users have control over their environment
By that logic, bash shouldn't, either. The problem with your logic is that a
user who doesn't have control over his own environment is a handicapped user, so
he can't really expect full functionality from anything. By not using $PATH,
all you're doing is handicapping those who _do_ control their environment.
> 2. Not all users know how to protect themselves from such attacks
Not all users know how to keep their password secret. Therefore, login(1)
shouldn't allow anybody to login.
> 3. Not all users feel the way you do -- they do want security, but
> they don't know how to get it, and simply don't have time to spend on
> figuring it out. It's a lot more complicated than most people
> understand, as you have very ably demonstrated.
Yup, security in a world where each program has a mind of its own is kinda hard
to achieve, don't you think? The first step towards security is convincing all
your programs to speak the same language: in our case, UNIX. In UNIX, what you
mean is what you say, plain and simple. "Bite me" means that I'd like you to
bite me. "Fuck you" means something that makes no sense. (I suspect it came
from "fuck yourself," which means that I'd like you to have sex with yourself.)
> By default, Mutt should help protect people from these kinds of
> attacks, because it CAN,
Mutt should not protect others' nonexistant rights at the expense of your real
rights.
> and because people expect it.
You'd like Webster's dictionary, then. Right in the introduction, they make it
very clear that they're not here to tell you how to speak English, rather to
tell you how people already speak English. You'll never learn correct behavior
from a follower, since Democracy inevitably leads him the wrong way.
> There's no
> good reason at all why Mutt can't use a sane default PATH,
The only sane default $PATH is the $PATH that Mutt is called with. Any other
$PATH is insane. Stuff that comes from outside Mutt isn't in Mutt's purview, as
you yourself said. (Correct me if I'm wrong.)
> which
> defaults to /bin:/usr/bin
That makes no sense. If a new version of gpg is in /usr/local/bin, it should
definitely be used in preference to the one in /usr/bin. Before you start
adding /usr/local in, though, what about the systems that have stuff installed
in /opt/bin, or /usr/ucb/bin? You're having difficulty solving this problem
simply because this isn't a problem that's yours to solve; you're not properly
equipped to solve the problem properly even for yourself, and certainly not for
the "thousands" of other programs on the system. Do everybody a favor, and
don't try to stick your nose in other programs' business.
> and can be overridden by the sysadmin at
> installation time,
The sysadmin should not have to reconfigure something he already configured once
(the default $PATH for users), just because Mutt insists on giving him the
equivalent of a confirmation dialog, with the wrong default value.
> and let users who need something else configure it
> manually by specifying absolute paths. You lose nothing.
If being UNIX-compatible is nothing to you, then yes, you lose nothing. On the
other hand, if you'd like to take advantage of the Mathematically proveable
security model that UNIX is built on, I'd strongly suggest letting UNIX protect
you, rather than plotting terrorist attacks against UNIX with the army that you
hope to use against an intruder.
> Your
> argument about you losing freedom to be Unix-compatible (which is
> totally nonsensical), when weighed against having your research
> stolen, or your friend's diary stolen, or having your own privacy
> invaded because you forgot to protect an attachment that you really
> didn't want to have protected is just trivial and silly.
You're putting the wrong pair of things on our scale. The second set of things
can be put to rest by simply having a sane security policy. A security chief
should know that, come on. . .
> And, getting back to your silly notion of Unix compatibility requiring
> applications to search the $PATH variable, that also is complete
> nonsense. Here's what IEEE 1003.1 (POSIX.1) has to say about the PATH
> variable:
>
> PATH
> This variable shall represent the sequence of path prefixes that
> certain functions and utilities apply in searching for an
> executable file known only by a filename. The prefixes shall be
> separated by a colon ( ':' ). When a non-zero-length prefix is
> applied to this filename, a slash shall be inserted between the
> prefix and the filename. A zero-length prefix is a legacy
> feature that indicates the current working directory. It appears
> as two adjacent colons ( "::" ), as an initial colon preceding
> the rest of the list, or as a trailing colon following the rest
> of the list. A strictly conforming application shall use an
> actual pathname (such as .) to represent the current working
> directory in PATH . The list shall be searched from beginning to
> end, applying the filename to each prefix, until an executable
> file with the specified name and appropriate execution
> permissions is found. If the pathname being sought contains a
> slash, the search through the path prefixes shall not be
> performed. If the pathname begins with a slash, the specified
> path is resolved (see Pathname Resolution). If PATH is unset or
> is set to null, the path search is implementation-defined.
>
> Nowhere therein does it say anything about applications being required
> to use $PATH to find applications. It doesn't even suggest that they
> should. It simply says that "certain functions and utilities apply
> [$PATH] in searching for an executable file known only by a filename."
> There is not now, and never was any requirement for applications to
> search the PATH to be "Unix-compatible."
Okay, you win. The IEEE has successfully screwed up one more aspect of UNIX.
All specs aside, though, consider some common sense: if the system provides a
service and the user exports a command in that language to a program, what makes
more sense: to take the command and run with it, or to take the command, throw
it on the floor, and reimplement an inferior version of the same service
yourself? Clearly, somebody forgot that simple, clean, orthogonal interfaces
are what allow UNIX to be so easily secured. You don't need to learn half a
zillion configuration syntaxes for half a zillion programs in order to tell each
of them how to find a secure version of gpg, since they all ignore your $PATH,
and cite the misguided wording of the IEEE drunkards as backup.
> The entire notion is
> completely inane, and a figment of your imagination.
I'm honored to be accused by such an important person of having invented the
UNIX philosophy singlehandedly.
> Your notion of
> "Unix-compatible" does not fit any definition of the term, other than
> the one you yourself made up.
Ditto
- Dave