Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!decvax!harpo!seismo!hao!hplabs!sri-unix!Michael.Young@cmu-cs-g From: Michael.Young@cmu-cs-g@sri-unix.UUCP Newsgroups: net.unix-wizards Subject: Re: chroot() {and why it's protected} Message-ID: <3131@sri-arpa.UUCP> Date: Fri, 15-Jul-83 11:06:33 EDT Article-I.D.: sri-arpa.3131 Posted: Fri Jul 15 11:06:33 1983 Date-Received: Sun, 17-Jul-83 16:32:02 EDT Lines: 20 Well, some utilities like to find some files in well-known places (from the root of the filesystem, that is). If you were able to, for example, link some setuid utility from /usr/xxx to your subtree (which is often possible on systems where /usr/foo is 'foo's home directory, and is on the same filesystem as /usr/bin, etc.), and then chroot there, you could fool it into thinking your version of a system file is real. A good example would be 'su' (if you could link to it, that is). All you'd have to do is make your own password file, and you could be anyone. Michael P.S. It still should be possible for utilities to determine that the current "root" directory is actually a filesystem root, and react accordingly, but none do. Plus, you couldn't tell mounted filesystems from the main one. Assuring that an /etc/, and other similar directories, couldn't be created on any mounted filesystem would help in this regard, but making chroot privileged is just a lot easier.