Xref: utzoo alt.security:1536 alt.bbs:2927 comp.unix.sysv386:362 Path: utzoo!attcan!uunet!samsung!usc!ucselx!bionet!snorkelwacker!husc6!encore!epeterso From: epeterso@encore.com (Eric Peterson) Newsgroups: alt.security,alt.bbs,comp.unix.sysv386 Subject: Re: Protecting against downloads Message-ID: Date: 14 Sep 90 12:43:15 GMT References: <8RFgP2w163w@mudos.ann-arbor.mi.us> Reply-To: epeterson@encore.com Organization: Encore Computer Corporation, Diagnostic Development Lines: 67 X-News-Reader: NN 6.4.9 mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: | epeterso@encore.com (Eric Peterson) writes: | > ** BZZZT! ** Wrong. People need to be able to read the kernel and | > other binaries. Changing the permission bits on the standard files is | > not necessarily a healthy idea. | | No, you're wrong. People don't need to be able to read the kernel; in | fact, on every modern Unix system I've seen, the ordinary user CAN'T | read the kernel. It's usually owned by "root", group "sysinfo" (or | something similar), and permitted 640 or 040. Programs like ps(1) | that need to read the kernel are SGID sysinfo. /dev/kmem, /dev/mem, | and /dev/swap are similarly owned by group sysinfo and permitted 640 | or 040. Any programs that have to access these protected files are | SGID sysinfo. | | The only executable files that need to be readable by the user are | shell scripts. As mentioned in another message, there is a program which can determine preprocessor symbols by digging them out of the cc binary, for which one has to have read permission on /bin/cc. Also, if you're working on a program which dives into the kernel and nlist(3) out the addresses for its data structures, having read permission on the kernel is also helpful. | > If you gave the command "chroot /usr/$HOME /bin/csh" instead | > of just "/bin/csh" as your shell command, the user would see | > "/usr/$HOME" as "/" and would not have access to /bin or /lib. | | Well, ignoring for the moment that "/usr/$HOME" will probably expand | to "/usr/u/loginid" or something similar, this opens up a security | hole big enough to drive a medium-sized planet through. Consider this: | | [[ Completely obvious example I didn't consider the first time ... ]] | | The user now has root. Kids, don't try this at home. THIS IS WHY | ROOT IS THE ONLY ONE ALLOWED TO EXECUTE chroot(1). Aha! I see your point. An even less healthy idea than before. However, if you were willing to take the time to do it, perhaps you could set up a branch of your file system to be a limited subset of your primary file system, with hard links from the subsystem into the main system for programs that users would need access to (sh, csh, cc, etc.). If you also linked in /etc/passwd, /etc/group, and so forth, you'd be set to present a limited subset of your main hierarchy. There's only two things wrong with doing this -- (1) it may take more time and effort than it's worth, and (2) it still doesn't solve the original problem. | The solution, as I mentioned before, is to remove read permission from | any and all binaries, INCLUDING the kernel. Make sure the hard drive | and raw hard drive devices are permitted 600. Make sure /dev/mem, | /dev/kmem, and /dev/swap can't be read by an ordinary user. All in all, it ends up boiling down to the question "Why do you want to give your users shell access?" To let them use the tools on the system to develop their own programs? To learn Unix? To experiment with various applications? How far do you trust them? What's your policy towards shell access? Eric -- Eric Peterson <> epeterson@encore.com <> uunet!gould!epeterson Encore Computer Corp. * Ft. Lauderdale, Florida * (305) 587-2900 x5208 Real Time: Here and now, as opposed to Fake Time, which is there and then.