Security

[MCLINDEN at RUTGERS.ARPA]

From:  Sean McLinden <MCLINDEN at RUTGERS.ARPA>


 Not 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
-------