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. 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.
There may not even be any one designated system administrator; all
users may share the system, and responsibilities of maintaining the
system, equally. In such cases, their personal security practices
absolutely can impact all of the other users. Mutt runs on such
systems.
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. 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.
The user's job is to adhere to the security policy and dilligently
protect all accessible computing resources, so that their exposure
does not harm the user, the system, or the organization on whose
behalf the user is working, if there is one. 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. 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. These
pitfalls include insecure temp file creation, symlink attacks,
inadequate default protections on newly created user data files,
sanitizing the user's environment to prevent unexpected/undesirable
behavior, careless use of relative paths, a wide variety of
vulnerabilities related to SUID binaries, if such are needed, and many
more than I could hope to discuss in this thread.
Whether or not YOU think so, whether or not YOU want it, programs MUST
do this. 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.
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.
In an earlier thread, you said something to the effect that
programmers do not have the right to take away freedoms to provide
security. 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.
If I put locks on my door, I take away your freedom to enter my home
freely, in order to safeguard my personal belongings. 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. 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.
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. People have a right to expect
that if they send you mail in confidence, you will respect that
confidence. 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. 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. 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. The very same goes for attachments,
temporary files, or any other file that Mutt creates which is related
to your mail.
Your security does unquestionably impact the security of others, all
the time, without you thinking about it or being aware of it. On
behalf of those others, Mutt can not and must not trust you to get it
right. 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.
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.
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. A malicious user -- perhaps someone intent upon stealing a
coworker's research -- could insert a trojaned copy of gpg which works
correctly for everyone except the target user, into the shared
directory. Like it or not, Mutt runs on such systems.
Mutt should not use the user's $PATH to find GPG (or any binary),
because:
1. Not all users have control over their environment
2. Not all users know how to protect themselves from such attacks
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.
By default, Mutt should help protect people from these kinds of
attacks, because it CAN, and because people expect it. There's no
good reason at all why Mutt can't use a sane default PATH, which
defaults to /bin:/usr/bin and can be overridden by the sysadmin at
installation time, and let users who need something else configure it
manually by specifying absolute paths. You lose nothing. 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.
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." The entire notion is
completely inane, and a figment of your imagination. Your notion of
"Unix-compatible" does not fit any definition of the term, other than
the one you yourself made up.
--
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:
pgpXb1iM5JG83.pgp
Description: PGP signature