Re: [PATCH] Remove absolute paths from gpg.rc
On Tue, Mar 20, 2007 at 01:11:56PM +0100, Vincent Lefevre wrote:
> On 2007-03-19 23:51:37 -0400, Derek Martin wrote:
> > If you have no clue, your trust is worthless. When we design the
> > security of our applications, we have to assume that the user is
> > completely clueless, because mostly they are. If you can specify the
> > full path to your GPG installation, I really don't see what the big
> > deal is. 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. I can't see any sane argument for this being bad.
> > Searching for applications via the PATH in a security-sensitive
> > context is, was, and always will be a potential source of security
> > problems.
>
> So is a full pathname. Whatever your choice is, this is a potential
> source of security problems. All this depends on the context. For
> instance, I was in some lab where machines were installed by the
> sysadmins, but after that, security patches were not applied, even
> when this was demanded by the user (this is bad, but what can the
> user do?). Debian has (had) a similar problem: due to dependencies,
> it can take months before a new package version can be installed in
> testing. In such cases, a solution is to compile the software manually
> and install it somewhere else (to avoid breaking the system and/or
> because the user doesn't have root access), e.g. in the user's home
> directory;
Here we see another effect of violating the UNIX philosophy. In the UNIX
philosophy, the user is assumed to know what's good for him, which is always a
safe assumption, since the user owns 100% of himself, and therefore is the only
one who can possibly have a stake in his own future.
> and using $PATH is a nice solution,
Indeed, it's the correct solution, in UNIX. (It's worth noting that UNIX itself
isn't the cleanest implementation of the UNIX philosophy. Compare $PATH to the
Plan9 solution to the path problem, for instance. Plan9 uses unionized objects
to create a unified /bin per process.)
> as the user doesn't
> necessarily know or remember which paths to update (not all software
> has a clear config file).
That's just further evidence that UNIX solved the path problem in the right
place - in the operating system itself. Remember that tidbit about orthogonal
interfaces?
> > The conclusion is that some kind of PATH protection should be
> > included. I favor compile-time hardcoded path, which can be specified
> > by configure option, and overridden in the config file by specifying a
> > full path. I'd also really like to see a configure option for mutt
> > refuse to run binaries in directories where the user has write access,
> > enabled by default, but whatever. [...]
>
> I completely disagree (for the above reasons, in particular). But
> *runtime* options are OK to enforce restrictions.
Options are always good, as long as defaults don't violate user rights.
(Obviously, a hardcoded path of any type is no good.) Users who are interested
in learning more about a program can read the docs, and flexibility is only
enhanced by having more options. The only legitimate reason to limit options is
to limit developer load. I don't see any reason to force users to use runtime
options for something that can be implemented in an orthogonal way as a
compile-time option (say, by having a compile-time option for the default value
of a runtime setting).
- Dave