neruda@function.mps.ohio-state.edu (Steve Neruda) (11/28/90)
Thanks to everyone who responded to my question about preventing single user mode booting in order to protect root. There were basically three solutions: 1) If you have source you could modifiy init to ask for a passwd before going into single user mode. 2) Dec will have new ROMs available (maybe already does). Is due out Spring/ Summer 91 for the 2100, 3100, and 5000. 3) Put some sort of passwd check in roots .profile file that will not allow itself to exit unless the root passwd (or a special passwd is typed in. The complexity for implementing this ranged from placing exec echo "Ultrix rules!" into roots .profile to C programs that are run from .profile. There were also several shell script implementations of this. The solutions I liked best we C programs that were run from .profile since they don't require alot of work, they can use the regular root passwd (though one even contained a second passwd if root was scrogged), they seemed pretty rugged (I couldn't get them to fail). Most of these solutions are pretty short so if people are interested I'll post a couple of them to an appropriate news group (comp.sources?). thanks again, steve neruda (neruda@geo2s.mps.ohio-state.edu
shwake@raysnec.UUCP (Ray Shwake) (11/29/90)
neruda@function.mps.ohio-state.edu (Steve Neruda) writes: >Thanks to everyone who responded to my question about preventing single user > mode booting in order to protect root. There were basically three solutions: [ two software solutions, one hardware solution (involving anticipated ROM upgrade) offered ] Well, how about pushing vendors to design hardware interlocks that prevent system boots, or disable terminal or keyboard response? Vendors installing identical locks on all systems such that anyone's keys work on anyone else' system (don't laugh... some do it!) would be subject to public shaming.
mjr@hussar.dco.dec.com (Marcus J. Ranum) (11/30/90)
In article <161@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: > > Well, how about pushing vendors to design hardware interlocks that > prevent system boots, or disable terminal or keyboard response? What, like the "locks" on IBM PC/ATs ? The ones that can be disabled instantly by unplugging a wire on the motherboard ? > Vendors installing identical locks on all systems such that anyone's > keys work on anyone else' system (don't laugh... some do it!) would > be subject to public shaming. I suppose you'd want the locks to somehow secure the cabinet as well, to prevent jumpering the lock-switch. And maybe then we'd need to add locking SCSI connectors, to prevent people from getting "root" by booting off of a different system disk. We need a locking cover on the tape drive, too, and so on, and so forth... Maybe a vendor who sells dup keys to their CPU (like IBM did) would have cause to be ashamed - but a user who is naive enough to place a great deal of trust in it should be ashamed, too. It is a placebo and they fell for it. Even with shell-scripts protecting singleuser boots, you still have to guard against spies who carry a spare SCSI shoebox around, and daisy-chain the disk onto your system, boot off it, mount root, and do Evil Things. The only system I ever saw that came close to solving these issues was a package for PCs that encrypted the FAT and made the disk unavailable until you cleared it with a password. Of course, when our user (who had insisted this was necessary) finally lost the password, I was able to grub around the disk with a disk-dumper and get the data back anyhow. You'd have to just encrypt *everything* on the disk, including the buffers in the bufcache, I suppose. :) - but I digress... mjr. -- If your windowing system is placing undue demands on your hardware and operating system, don't ask yourself what can be done to improve the operating system or hardware - ask yourself why you are using that windowing system. [from the programming notebooks of a heretic, 1990]
dan@gacvx2.gac.edu (11/30/90)
In article <1990Nov29.221947.21056@decuac.dec.com>, mjr@hussar.dco.dec.com (Marcus J. Ranum) writes: > In article <161@raysnec.UUCP> shwake@raysnec.UUCP (Ray Shwake) writes: >> >> Well, how about pushing vendors to design hardware interlocks that >> prevent system boots, or disable terminal or keyboard response? > > What, like the "locks" on IBM PC/ATs ? The ones that can be > disabled instantly by unplugging a wire on the motherboard ? > >>>>DELETED<<<< - a triade of nothing is secure!!! You are correct, any system devised my man can, in time, be undone by man. Computers just make it take less time. A single user boot is a quick, undetectable, way to gain priviledged access to a computer system. Just because it is probably not possible to devise a system that would prevent any unauthorized access, does not mean it should be left wide open. I do expect a system vendor to make it difficult to get my data, not impossible. More than once I have been glad for back doors into the computers I manage. It should take more than one cracker telling another "Just type 'b -s' and the system is yours..." In my environment (a college) absolute data security is not an issue, however confidentiality of data, and damage to data due to unathorized/possibily malicious access is. Trying running a lab of Macintosh or PC's, with hard disks, with novice users, for a week, without a tape backup and you will know what I mean. Workstations are moving out of the power users office and into the computer lab! -- Dan Boehlke Internet: dan@gac.edu Campus Network Manager BITNET: dan@gacvax1.bitnet Gustavus Adolphus College St. Peter, MN 56082 USA Phone: (507)931-7596
pcg@cs.aber.ac.uk (Piercarlo Grandi) (12/02/90)
On 27 Nov 90 21:16:21 GMT, neruda@function.mps.ohio-state.edu (Steve Neruda) said: neruda> Thanks to everyone who responded to my question about preventing neruda> single user mode booting in order to protect root. There were neruda> basically three solutions: The best solution is of course to protect the network from any sysadmin who thinks that this is anything else than a security hazard (again: the greatest security hazard is a false sense of security). Or maybe to send him/her to a course on basic principles of security. Or maybe to induce him/her to read something about project Athena (or Andrew) and their solutions -- effective (if not perfect) solutions, instead of jokes, I mean -- to the problem. Maybe there should be a FAQ posting in this newgroup and this should be part of it -- the issue gets raised again and again always in the same depressing way. It is understandable that hard pressured syadmins have no time for hard thinking and reach for the quick and dangerous fix... Or maybe I should paraphrase the nice Feynman quote that somebody uses as their signature line: "For a successful security, reality must take precedence over public relations, for hackers cannot be fooled." -- Piercarlo Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk
mra@srchtec.UUCP (Michael Almond) (12/06/90)
While I was installing Ultrix 4.1 on our DEDsystem 3100 I came across the intructions for doing this. It requires a little hacking in the rc. Just thought I'd mention this. --- Michael R. Almond (Georgia Tech Alumnus) mra@srchtec.uucp (registered) search technology, inc. emory!stiatl!srchtec!mra Atlanta, Georgia (404) 441-1457 (office) [search]: Systems Engineering Approaches to Research and Development