On Sat, 29 Sep 2007 18:00:18 +0200 (CEST)
Magnus Eriksson <magetoo@fastmail.fm> wrote:

> 
> On Fri, 28 Sep 2007, John Nemeth wrote:
> 
> >     Sure, but I think this is just being paranoid.  Only root can
> > setup those directories.  If anything else manages to do so, then
> > you're already screwed.
> 
> 
> On Sat, 29 Sep 2007, Steven M. Bellovin wrote:
> 
> > I do not agree that it's a hole.  I think it's correct to
> > include /usr/local in default paths -- /usr/local/bin for
> 
> 
>    I should probably explain the scenario I'm seeing here.  My
> concern is that a bug in a suid program will allow the
> directory /usr/local/bin to be created, with permissions such that a
> malicious user can put his own binaries there.  Then the next time
> root types "sl" instead of "ls" you're screwed.

I think we all understand your concern; we just disagree.
> 
>    I'd say that the obvious solution is to not have /usr/local in the
> PATH at all, or to set things up right in the first place, with
> appropriate permissions.  (I think most people were already in
> agreement about reinstating /usr/local ...)
> 
> 
>    And I don't see how it follows that you're automatically screwed
> just because a buggy suid root binary can be exploited to create a
> directory. As long as you don't have an obvious target for creation,
> like there is now.
> 
The question, then, is how to weight the possibility of a bogus
directory creation vs. the costs of not having /usr/local.

First -- I regard the possibility of bogus directory creation -- where
the directory is writable by the enemy -- as low.  Bogus file creation
is rather more common, if only because many more programs create files
-- and hence could be tricked into creating the wrong file -- than
directories.  The only way I see this as likely is if /usr/local is
created with the wrong modes.  The solution is simple, of course: make
sure it's created at system install time, as well as /usr/local/bin,
etc. A pre-existing /usr/local/bin, with the proper ownership and
modes, is no more dangerous than /bin or /usr/bin.

Second -- if you think that bogus directory creation is a risk,
there's a bigger problem: /etc/skel/.profile and /etc/skel/.cshrc both
put ~/bin ahead of everything else in $PATH.  Create one of those and
wait for your sysadmin to type su or some such.

Third -- lack of system maintainability is itself a security risk,
because it makes it harder to upgrade when that's needed.  (Quick --
who among -current users has never skipped /etc/update because it's
such a PITA to run?)

Security is not an absolute goal.  Rather, it's one goal among many,
and has costs and benefits.  I'm certainly not saying you should ignore
security, or even that it's unimportant -- far from it; I make my
living doing security stuff -- but I do suggest that the problem is
more complex.

		--Steve Bellovin, http://www.cs.columbia.edu/~smb