From owner-freebsd-hackers  Fri Oct 18 14:25:54 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id OAA24394
          for hackers-outgoing; Fri, 18 Oct 1996 14:25:54 -0700 (PDT)
Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id OAA24372
          for <freebsd-hackers@freebsd.org>; Fri, 18 Oct 1996 14:25:37 -0700 (PDT)
Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.7.6/8.7.3) with SMTP id OAA12159; Fri, 18 Oct 1996 14:22:04 -0700 (PDT)
Message-ID: <3267F479.773C2448@whistle.com>
Date: Fri, 18 Oct 1996 14:19:53 -0700
From: Julian Elischer <julian@whistle.com>
Organization: Whistle Communications
X-Mailer: Mozilla 3.0b6 (X11; I; FreeBSD 2.2-CURRENT i386)
MIME-Version: 1.0
To: Guido.vanRooij@nl.cis.philips.com
CC: freebsd-hackers@freebsd.org, Andrew.Tridgell@anu.edu.au
Subject: Re: fix for symlinks in /tmp (fwd) FYI
References: <199610181859.UAA14544@spooky.lss.cp.philips.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk

Guido van Rooij wrote:
> 
> ----- Forwarded message from Andrew Tridgell -----
> 

> The patch changes the kernels namei code so that symlinks will not be
> followed if:
> 
> 1) the t bit is set on the directory containing the symlink
> and
> 2) the euid of the process does not match the owner of the symlink.
> 
> The patch explicitly includes root, so root will not be able to follow
> symlinks in /tmp unless it owns them.
> 
> I believe this change fixes all the "symlink-in-/tmp" style of
> security holes while having a minimal impact on the normal use of
> symlinks.

I wonder if anyone can comment on this...
My initial reaction is that it's breaking the expected behaviour
or the system to do this....
If I see a symlink I expect it to be followed..

> 
> In case you don't think this change is necessary you should think
> about how many recent security holes in unix-like systems have been
> due to sloppy coding of programs that create files in /tmp. I also
> noticed today that gcc is vulnerable to this kind of bug (as of
> version 2.7.2), so potentially you can attack anyone who compiles
> anything on your system.

anyone from the BSD security group have comments?

> 
> I know there have been other proposed generic fixes for this style of
> bug, but they tend to suffer from the problem of requiring people to
> change the way they work. The above fix should not be very noticeable
> to normal users of a system.

until they stumble over it.

> Can anyone see any problems with this proposal?

I just don't like it?


julian