Re: [PATCH] Remove absolute paths from gpg.rc
I'm an idiot.
On Wed, Mar 21, 2007 at 03:35:18PM +0000, Dave wrote:
> 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)
, is also extremely expensive on the attacker's end (since it essentially
requires every attacker to actively circumvent boobietraps, thereby violating
the UNIX philosophy of doing _one_ thing (as well as the KISS principle),
thereby lowering his own efficiency at attacking your system)
> .
Sorry about that,
- Dave
On Wed, Mar 21, 2007 at 03:35:18PM +0000, Dave wrote:
> 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