<<< Date Index >>>     <<< Thread Index >>>

Re: [PATCH] Remove absolute paths from gpg.rc



On 2007-03-21 00:27:10 +0000, Dave wrote:
> On Tue, Mar 20, 2007 at 12:14:17PM +0100, Oswald Buddenhagen wrote:
> > On Tue, Mar 20, 2007 at 07:28:36AM +0000, Dave wrote:
> > > On Mon, Mar 19, 2007 at 11:51:37PM -0400, Derek Martin wrote:
> > > > I'd also really like to see a configure option for mutt refuse to
> > > > run binaries in directories where the user has write access,
> > > 
> > > I think that's a useful option.
> > > 
> > it sort of defeats ~/bin.
> 
> Well, you can "lock" ~/bin by chmod(1)ing u+w ~/bin before every
> time you add or remove a local script/program, and u-w after you're
> done.

So, what's the point of preventing Mutt from running binaries from
such directories?

Note that if the user saves a file from an external source to bin by
mistake, the file won't have the x bit set. So, there's no problem.
And if a chmod can be done on the file, it can also be done on the
directory.

> > the most secure solution is already the default: no sane program (except
> > the linker) creates/saves files with an executable bit set. this is a
> > conscious decision of the user - at the point where it is not, the
> > security was already compromised.
> 
> I don't disagree with your last statement. However, some people may
> appreciate the added bit of security gained by extra restrictions on
> program execution.

If the user doesn't trust his $PATH or what he installs in his bin
directory, he can still use full pathnames. But a *compile-time*
option would be a bad idea, as the one who installs the software
is not always the one who uses it.

BTW, a shell with restrictions would be a much better idea.

-- 
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)