Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!linus!philabs!seismo!hao!hplabs!sri-unix!MCLINDEN@RUTGERS.ARPA From: MCLINDEN@RUTGERS.ARPA Newsgroups: net.unix-wizards Subject: Security Message-ID: <2825@sri-arpa.UUCP> Date: Wed, 6-Jul-83 18:04:52 EDT Article-I.D.: sri-arpa.2825 Posted: Wed Jul 6 18:04:52 1983 Date-Received: Mon, 11-Jul-83 00:09:39 EDT Lines: 48 From: Sean McLindenNot meaning to beat a dead horse, I think that it would be worthwhile to distinguish between those playful users who are "friendly" but mischievous and those who (if given the opportunity), would do harm to a system. In the first category might be included co-workers and system programmers (hackers). In an office setting, it may be nearly impossible to keep passwords a secret and anyone who has access to the machine console could easily bring the system down and back up in a single user mode, security notwithstanding. Having been both a system administrator and a programmer it seems to me that securing a system from the playful but trusted user is more a matter of education and less one of heavily guarding machine and system secrets (which is all but impossible anyway). The non-trusted user is a different story. Amost anyone with the desire can learn the inner workings of UNIX. Unlike IBM and (to a certain extent, DEC operating systems), practically eveyone who has UNIX license (educationally), has a source license and the sources are easy to get a hold of. The idea of creating restricted shells has been mentioned before and is frought with possibilities. For example, consider the following (very trivial), example: /* newroot.c */ main() { chroot ("/usr/guest"); execlp ("csh" , "csh" , "-f " , 0 , 0); } This program, run setuid root, will create a shell (csh), whose idea of "root" is /usr/guest. Done properly, chroot (which exists in 4.1 but which isn't documented), could be used to create systems with their own "super user", their own password files, and assuming that these separate roots can run init(), a system could be created completely secure from other systems on the same machine. The drawback is, of course, that certain files and utilities would have to be duplicated for each system. On the other hand this may be one mechanism for isolating potential trouble spots from the entire system. Sean McLinden -------