Re: [PATCH] Remove absolute paths from gpg.rc
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; and using $PATH is a nice solution, as the user doesn't
necessarily know or remember which paths to update (not all software
has a clear config file).
> 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.
--
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)