acu@stat-l (Shoe) (09/29/84)
I think a serious oversight by Berkeley when adding symbolic links was the failure to add a sys call (or library routine) that resolves an arbitrary path into a path guaranteed to be free from symbolic links. (No, this is not trivial to do with readlink). This would be especially useful when you have to back up to check the permissions of a file's parent directory. Access is just not flexible enough. -- Mark Shoemaker /dev/shoe ...!pur-ee!pucc-k:acu mas@purdue The way to do is to be. -- Lao Tzu
henry@utzoo.UUCP (Henry Spencer) (10/01/84)
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.
--
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henryrichardg@elecvax.OZ (Richard Grevis) (10/17/84)
> 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
henry@utzoo.UUCP (Henry Spencer) (11/08/84)
> 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. > ... Once an implementor > thinks about such things ... > ... then programs could be made *without* these recurring bugs. Thinking before coding is something the Berklix authors didn't do very consistently. This is not to say that USG/USDL/whatever-it-is-this-week is any better; most of *those* people can't think at all. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
kre@mulga.OZ (Robert Elz) (11/13/84)
| > 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. | > ... Once an implementor | > thinks about such things ... | > ... then programs could be made *without* these recurring bugs. | | Thinking before coding is something the Berklix authors didn't do very | consistently. This is not to say that USG/USDL/whatever-it-is-this-week | is any better; most of *those* people can't think at all. | -- | Henry Spencer @ U of Toronto Zoology | {allegra,ihnp4,linus,decvax}!utzoo!henry 4.2 must be the most widely pre-discussed, and pre-publicised system of all time - just think back 18 months ago, (or so) look at all the news "x is going to be in 4.2".... (Then go back, way back another 2 years, to when it all started) There was plenty of thought about those issues that were issues. Security, though, was not a major issue - when you get a 4.2 system, you get the system that Berkeley prepared for ARPA. There were certain goals, tight security was (to the best of my knowledge) never one of them. If you don't like that, then run something else. Basically, Berkeley (and I suspect Bell) have environments where the users are expected to be, and are, considerate of the system. Security on those systems is a method to protect against accidents, not against invasions. That has the advantage, that breaking into such a system provides no glory at all - its simply tedious, stupid, and anti-social. (So intelligent people don't bother trying) Robert Elz decvax!mulga!kre ps: Henry - How do you manage to find a job where you get time to post all that news ?? :-)
henry@utzoo.UUCP (Henry Spencer) (11/16/84)
> There was plenty of thought about those issues that were issues. You mean, about those issues that people thought were issues. I've seen no evidence that anyone realized that symbolic links are a significant change to the semantics of the pathname->file mapping. It is hard to imagine anything more central to UNIX. Yet symbolic links appear to have been treated as a trivial extra. I stand by my original statement: the implications of symbolic links were not fully understood. They still aren't. By anyone. > Security, though, was not a major issue - when you get a 4.2 > system, you get the system that Berkeley prepared for ARPA. > There were certain goals, tight security was (to the best of > my knowledge) never one of them. If you don't like that, > then run something else. If ARPA said anything explicit about it at all, I would suspect that "security no worse than 4.1BSD" would have been mentioned. It is one thing to say that tight security was not an issue; it is another to weaken security seriously without telling anyone, and (apparently) without even realizing it was happening. > ps: Henry - How do you manage to find a job where you get time > to post all that news ?? :-) A religious policy of unsubscribing to non-technical newsgroups frees up a remarkable amount of time... :-) -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
steveg@hammer.UUCP (Steve Glaser) (11/20/84)
Symbolic links are not a security hole to "normal" users. There is no bypassing of normal kernel level protection checks for the directories traversed along a pathname or for the file eventually pointed to. The only kind of programs that can have trouble are those that try to build restricted environments (restricted shell for instance). Even there, the hole is not in the normal unix protection checks, but rather that the program implementing the restricted environment is not sufficiently restricted. That is certainly an issue, but it is an incompatability issue that MAY introduce security problems into existing restricted environments, not a security hole in the kernel protections. Summary: If I "chmod 700 dir" there is no NEW way that anyone other than me (or root) can get into dir. (where NEW means introduced by 4.2 BSD). Steve Glaser tektronix!steveg steveg.tektronix@csnet-relay
jdb@mordor.UUCP (John Bruner) (11/21/84)
Symbolic links DO create additional security problems. The presence of symbolic links in 4.2BSD widens a security hole that existed in 4.1BSD (and I believe also exists in System V) into a yawning chasm. I don't want to elaborate on this, other than to say that sometimes it was indeed a feature that you could not hard link across filesystems. I'm not opposed to symbolic links, but I do believe that more thought should have been given to their implementation. As just one example, the implementation of "chown" and "chmod" with respect to links is inconsistent. "chown" changes the owner of a link, but "chmod" changes the mode of the file that the link points to. -- John Bruner (S-1 Project, Lawrence Livermore National Laboratory) MILNET: jdb@mordor.ARPA [jdb@s1-c] (415) 422-0758 UUCP: ...!ucbvax!dual!mordor!jdb ...!decvax!decwrl!mordor!jdb
richardg@elecvax.OZ (Richard Grevis) (11/27/84)
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.