Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B UNSW 1.1 19 Sep 1984; site elecvax.OZ
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!mulga!munnari!basser!elecvax!richardg
From: richardg@elecvax.OZ (Richard Grevis)
Newsgroups: net.bugs.4bsd
Subject: Re: Symbolic Links VS. Security
Message-ID: <378@elecvax.OZ>
Date: Wed, 17-Oct-84 02:38:12 EST
Article-I.D.: elecvax.378
Posted: Wed Oct 17 02:38:12 1984
Date-Received: Thu, 8-Nov-84 00:49:52 EST
References: <442@unmvax.UUCP> <159@utecfa.UUCP>, <150@stat-l> <4394@utzoo.UUCP>
Organization: EE and CS, Uni of NSW, Sydney, Australia
Lines: 46


  > Actually, I've thought for some time that many security implications
  > of symbolic links were not well understood when they were put into 4.2.

This is something of an understatement.  I find it doubtful that
the security implications were thought about at all, and if they
were, they must not have had the time to thus fix the distribution
software.  Symlinks may be described as the link you have while not
having a link.  Programs that used to aid security by looking at the
link count of a file must also now do symstat (or whatever it is)
to do the job properly.  Systems that were secure in a practical sense
because nasty directories like /tmp were on a separate filesystem,
suddenly are no longer secure. For example, symbolic links suddenly
made the implications of the predicable mail bugs in 4.1c very important.
I replaced the password file with my own version of it, whereas before
I could only wreak havoc on the /tmp filesystem.

As a person isolated from the US, I can only wonder why the UNIX
tools (and system) implementors don't take more care with security.
There are VERY well known general techniques for breaching security,
insomuch as there are known weak spots in programs.  Once an implementor
thinks about such things, (and they only have to be documented in some
check list fashion), then programs could be made *without* these recurring
bugs.

Perhaps a concrete example;

What do you do with your temporary file?  If it is in /tmp, then
another process can unlink it and replace it with their own.  This
is no problem SO LONG AS you maintain your original file descriptor
into the file.  A fd is the one thing that is an unpreemtable window
into a file. 4.1bsd mail however, opens and closes its temporary file
like it is going out of style, so straight off you can read any
file that you can link into /tmp, and further, by exploiting a
race condition of sorts, you can add information to any file you
can link to.  Why?  Its not the whole story, but mostly because
mail opens and closes a temporary file in a dangerous place.

Moral?  Security problems should be documented, and the general
reasons for the problems distilled from them.  Then we can *all*
avoid the problems.

Richard Grevis,
Joint Microelectronics Research Centre,
Australia.
	...decvax!mulga!cadvax!richardg