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
