Re: [PATCH] Remove absolute paths from gpg.rc
On Wed, Mar 21, 2007 at 01:49:45PM +0100, Vincent Lefevre wrote:
> 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?
First off, I'm not in favor of adding it because I can prove how it improves
security, but rather simply because somebody feels it can improve security, and
it doesn't really hurt the code much to add this feature. We certainly wouldn't
have an easy time proving that it can _never_ improve security. Remember,
Derek's solution to the security problem is to install as many boobietraps as
possible between an invader and a vulnerability, and it's trivial to show that
his solution, while extremely expensive on the programmer's end (since it
essentially requires every program to actively insert boobietraps, thereby
violating the UNIX philosophy of doing _one_ thing, as well as the KISS
principle that the entire worldview that the UNIX philosophy is based on is
rooted in - now you know why Churchill might've been wrong about prepositions at
the ends of phrases being okay).
That said, I'd like to take a shot at showing at least one case where we might
successfully fend off a half-hearted attack with this boobietrap: If an intruder
can somehow creat(2) a file with the X bit set (but has no access to the
chmod(2) call - say, he has the opportunity to manipulate the flags of a
creat(2) call somehow), then if a directory in the $PATH is writeable, he may be
able to capitalize on the opportunity to displace a common utility without
Derek's boobietrap.
Derek's philosophy is about agressively trying to harrass an adversary at every
single corner (much like old "encryption" systems), rather than implementing all
security in one strong wall that's simple enough so we can easily prove its
theoretical security (much like a modern encryption system). It's also easier
to maintain a program that doesn't have boobietraps strewn everywhere, since
there are fewer opportunities for a change to accidentally nuke a "micromine"
without anybody noticing. Next, it's important to note that sticking to the
KISS principle allows programmers who aren't security experts to create (and
maintain) easily auditable programs; obviously, not requiring programmers to be
security experts in order to build secure software (a) increases the number of
available programmers who can build secure software, and (b) better matches
reality, where most programmers are not security experts. (The only problem is
that "security experts" then lose a lot of consulting work.) Finally, it's far
easier to educate a user in the science of opening doors conservatively than in
the art of maximizing confrontations with potential intruders using half a
zillion "micromines" in (what the programmer (who, of course, may not be a
security expert) considers) strategic locations.
> 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.
Well, if our intruder can manipulate the flags on a chmod(2) call, but can't
modify the file argument, he still may be able to chmod(2) a particular file,
but not necessarily the directory it's in. The other option is if the intruder
can manipulate the file argument, but the flags are set to 0700 or something.
In that case, you could chmod(2) the directory if you wanted to, but you'd have
to find another way to chmod(1) u-w the directory before your planted binary
could be executed by Mutt. (Obviously, if the user were to execute a
"non-security-critical" program that had the misfortune of trying to execute the
utility displaced by your new binary, the user would be just as screwed, but
Derek would probably counter that _all_ programs must (re)implement the
boobietraps in order to block this type of problem. Are you starting to see why
simple, clean, orthogonal interfaces are so cool? Dennis Ritchie may not have
been a security expert, but he's always been a very wise man.)
> > > 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.
I'm sure there are cases where a ban on trusting $PATH can be a useful
boobietrap (i.e., can stop at least one half-hearted attack).
> 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.
The one who installs the software should be the system administrator, who's (an
agent of) the owner of the system. It's his domain to make these types of
decisions about his system. How about runtime options having two shadow
compile-time options, default-blah and force-blah? Normally, a sysadmin would
only set default-blah options (or none at all, ideally), but when a sysadmin
decides to pursue the boobietrap approach, he still has the option of setting
force-blah options. This type of scheme should be fairly easy to maintain from
a programmer perspective. How does that sound?
> BTW, a shell with restrictions would be a much better idea.
smrsh?
- Dave