Xref: utzoo alt.security:1522 alt.bbs:2911 comp.unix.sysv386:318 Path: utzoo!attcan!uunet!cs.utexas.edu!usc!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: 13 Sep 90 12:14:00 GMT References: <22@tdw205.ed.ray.com> Reply-To: epeterson@encore.com Organization: Encore Computer Corporation, Diagnostic Development Lines: 73 X-News-Reader: NN 6.4.9 ralphs@halcyon.wa.com (Ralph Sims) writes: | heiser@sud509.ed.ray.com (Bill Heiser - Unix Sys Admin) writes: | | > A *ix sysop I communite with recently told me that he'd caught one of | > his "shell-access" users downloading *ix binaries. | | Sounds like he left HIMSELF open. Of COURSE he left himself open to such activity -- why else would he ask the net for help? | > As far as I can see, we either have to trust the users that we give | > shell access to, or make kermit/sz, etc unavailable to them. I guess | > we could just make downloads only available thru the "bbs", rather than | > from the shell ... | | How 'bout privileges on the files? If the user didn't have read permission, | then he wouldn't have got them (maybe? I don't speak unix, but I'm sure | someone will follow through on this). ** 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. | > Anyone else have any ideas on this? How do you all deal with this? | | Watch your back. This is true. But unhelpful. | Protect your files. This is what he's asking how to do. | Don't give shell users root access. Finally! A useful bit of information. Not much information, but more so than the rest of the previous message contained ... I would guess the user was downloading binaries that normal shell users would need, such as the contents of the /bin, /usr/bin, /etc, or /lib directories, as well as possibly the kernel itself. This presents the dilemma -- if I give the user access to those files for shell use, he can then download them. What you might do is write a shell script (or hack the xmodem, kermit, or sz code) to check the user and group ID for each file that is being attempted to be transferred. If the UID and GID are "root" or "sys" or "bin" or some other system ID, then deny access to the file. Otherwise, let it go through as normal. There is also a command under System V called "chroot". What that will do is create a virtual root for a running process, and all file access done by the process will be relative to that root. You might want to consider using this function, but be careful with it -- by using it, you basically isolate a process to one particular branch of the file system, thereby isolating other parts of the system. For instance, 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. | Run an MS-DOS system. ACK!! What makes MS-DOS so much better than Unix? If I had DOS shell access, I could still download the DOS binaries, so the problem would still exist, right? How would you solve it with a DOS system? 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.