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: <422@elecvax.OZ> Date: Mon, 26-Nov-84 16:25:02 EST Article-I.D.: elecvax.422 Posted: Mon Nov 26 16:25:02 1984 Date-Received: Wed, 28-Nov-84 02:01:50 EST References: <442@unmvax.UUCP> <159@utecfa.UUCP> <150@stat-l> <4394@utzoo.UUCP> <1011@hammer.UUCP> Organization: EE and CS, Uni of NSW, Sydney, Australia Lines: 34 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.