Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!chinacat!sequoia!rpp386!jfh From: jfh@rpp386.cactus.org (John F Haugh II) Newsgroups: comp.unix.internals Subject: Re: Complex security mechanism is unsecure Message-ID: <18827@rpp386.cactus.org> Date: 17 Dec 90 00:38:47 GMT References: <4627@pkmab.se> <18808@rpp386.cactus.org> <6886@titcce.cc.titech.ac.jp> <4645@pkmab.se> <6922@titcce.cc.titech.ac.jp> Reply-To: jfh@rpp386.cactus.org (John F Haugh II) Organization: Lone Star Cafe and BBS Service Lines: 58 X-Clever-Slogan: Recycle or Die. In article <6922@titcce.cc.titech.ac.jp> mohta@necom830.cc.titech.ac.jp (Masataka Ohta) writes: >Then, for example, think about a case where NFS mounted file system >is exported with root access converted to nobody (but, uucp to uucp, >daemon to daemon). Then, list what system administrators should take care. How about starting with exporting the file system read-only and only to systems which are properly administered. Secure systems cannot exist in an open environment with insecure ones unless you prevent the insecure ones from accessing your system. If you are exporting your filesystems to the entire world read-write, and your neighbors don't care about security you will NEVER have a secure system. >>Really, I think that the addition of more >>than one ring of security by using other uids than only root is very >>valuable and costs next to nothing in extra complexity. > >And you can have seven levels of security like Multics without >extra complexity. Perhaps if Multics had insecure network filesystems such as NFS it would still have required added complexity, no? >My point is that root become more vulnerable if it trust uucp, daemon >and others. This is neither new information nor interesting. There is no special relationship between "uucp" and "root" above and beyond the relationship between an ordinary user and "root". If the security of your system is dependent on the security of any non-root user account (such as "uucp", "bin", "sys", etc.), any compromise in the security of that account, either by NFS mounts or carelessly giving out "bin" or "uucp" passwords is going to directly impact the security of the system. "root" should not carelessly trust a poorly administered "uucp" system any more than it should trust Joe Luser. We know this already. >Moreover, if I remember correctly, in 4.2BSD, /etc/syslog was owned >by daemon, which will be executed by root at boot time from /etc/rc.local. >At least, on SunOS 3.5, /usr/etc/in.syslogd is owned by daemon and >executed by root. By the standards of security which you wish to claim are required, EVERY executable on the system must be owned by root, and all the files used by all those executables must also be owned by root. And so on. All that is actually required is some statement that the executable in the directories which root can execute from are "trustable", and so on for the configuration files. Start with not granting access to the accounts owning the files, directly or otherwise. Yes, and NFS is a botch. What else is new? -- John F. Haugh II UUCP: ...!cs.utexas.edu!rpp386!jfh Ma Bell: (512) 832-8832 Domain: jfh@rpp386.cactus.org "While you are here, your wives and girlfriends are dating handsome American movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson."