Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!execu!sequoia!rpp386!jfh From: jfh@rpp386.Dallas.TX.US (John F. Haugh II) Newsgroups: comp.unix.wizards Subject: Re: Getting rid of the root account Message-ID: <16658@rpp386.Dallas.TX.US> Date: 10 Jun 89 01:49:11 GMT References: <106326@sun.Eng.Sun.COM> <4315@ficc.uu.net> <16597@rpp386.Dallas.TX.US> <1961@ubu.warwick.UUCP> <16638@rpp386.Dallas.TX.US> <10370@smoke.BRL.MIL> <16650@rpp386.Dallas.TX.US> <1989Jun8.210946.26746@eci386.uucp> Reply-To: jfh@rpp386.cactus.org (John F. Haugh II) Organization: River Parishes Programming, Plano TX Lines: 50 In article <1989Jun8.210946.26746@eci386.uucp> jmm@eci386.UUCP (John Macdonald) writes: >1. get rid of all root logins from the normal /etc/passwd Now that's a good start :-) >2. get rid of all suid-root programs that have not been fully verified Yes, you must do this as well. /bin/mkdir will always be a member of my bag of tricks. >3. create suid- programs to manage privelged activities for > each different you need. You may need to write (and prove > correct) a suid-root permission management program for complicated > cases. This is not adequate. There are many operations under UNIX which only root can perform. The idea behind making 0 a non-special UID is that than you must have some other object with a finer granularity in order to perform the operation. Certainly you could have every utility check it's invoker to verify permission - but what do you do when a bug such as /bin/mkdir crops up and demonstrates how little security stock UNIX has designed into it? >This setup allows the kernel to be proved since there is not a huge amount >of requirement - it must not give out root permission gratitously, it must >implement suid correctly. It allows any site to configure its own security >requirements without having to make any change to the kernel. It allows the >typical system be sold as reasonably secure without the high expense of proof >which satisfies needs of most systems[1]. Proving a kernel secure is not sufficient. You must also prove that all of the programs executing with privilege are secure. By creating more programs to manage privilege you are creating a larger task. Assurance goes straight out the window since any one flaw in the program affects all of the privileges the program posseses, and that is every privilege. >It puts the cost of proving or validating any additional security needs on >those people who require and implement those needs. This does not preclude >providing some programs which do some of these tasks either with the system, >or in any other fashion (comp.unix.sources); but people who *require* >security will have to validate such programs anyhow. ... Which is the consumer. Provably secure systems will not be running the latest version of nethack or smail. -- John F. Haugh II +-Button of the Week Club:------------- VoiceNet: (512) 832-8832 Data: -8835 | "AIX is a three letter word, InterNet: jfh@rpp386.Cactus.Org | and it's BLUE." UucpNet : !bigtex!rpp386!jfh +--------------------------------------