Symbolic Links VS. Security

[Richard Grevis]

I can only concur with others who state that symbolic links introduce
security problems.  While your claim that symbolic links do not directly
introduce security bugs is in some sense true, it is a very narrow
interpretation of what actually happens.  First off, UNIX system
calls actually have "semantics", to a greater or lesser degree, and
programs assume things about the meaning and implications of system
calls.  Symbolic links markedly change the semantics of system calls.
For example, if stat says that a file only has 1 link, do you believe
it?  If access says that a file does not exist, do you believe it?
Therefore all our lovely debugged and secure [:-)] programs, like
mail, uucp, etc, suddenly may not be secure.  They may assume
that if a file only has one link (using stat), then it exists
only on the file-system and directory in question. Wrong.
Programs may assume that if access fails, then it can creat a file
and 1) the file is new, and 2) the file is in the directory and file-system
that it thinks it is.  Wrong.

In truth the above things that I detail have security problems
anyway, because there is a critical region AFTER the check, and
BEFORE the action.  Symbolic links make these problems turn hard
on, and make them trivial to exploit.  What can I say, symbolic
links made it easy for me to become root on 4.1c and 4.2 systems,
and in all cases I didn't write any C code, just shell files.

In summary, John Bruner is right.  For better or worse, it is a
great feature that no links can occur across file-systems.  Thus
by ensuring that /tmp, user directories, and most other things are
all on separate file-systems, you can minimise the impact of known
and future bugs, because most involve linking.  If there is nothing
interesting to link to, then nothing interesting will happen.

		Richard Grevis  (decvax!mulga!richardg)
		Joint Micro-Electronics Research Centre,
		University of NSW.