mju@mudos.ann-arbor.mi.us (Marc Unangst) (09/05/90)
epeterso@encore.com (Eric Peterson) writes: > 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. I think it's a safe assumption to make that the type of user who has to dig preprocessor symbols or dig into the kernel data structures is rather different from the user who logs on and tries to download your binaries. If the user needed to do this, you might want to put them in /etc/group as a member of "sysinfo" and let them newgrp(1) to sysinfo when they test their program. Special arrangements can be worked out for special situations, but I feel my basic argument still holds: On a "normal" Unix system that isn't being used for production, users should not have read access to any of the binaries, the kernel, or /dev/{kmem,mem,swap}. > 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? This all depends on what your system is being used for. Naturally, a system that's used for hacking the kernel sources is going to be set up differently from an X server that users log into over the network and run a database or something. I don't run a Unix BBS now, but I have in the past and may in the future. My policy is to make sure system security is reasonably tight, and then let users have shell access. It's worked fine in the past. -- Marc Unangst | "da-DE-DA: I am sorry, the country you have mju@mudos.ann-arbor.mi.us | dialed is not in service. Please check the ...!umich!leebai!mudos!mju | number and try again." -- Telecom Kuwait
heiser@sud509.ed.ray.com (Bill Heiser - Unix Sys Admin) (09/12/90)
A *ix sysop I communite with recently told me that he'd caught one of
his "shell-access" users downloading *ix binaries. Since I'm getting
ready to set up my system for public access, this concerns me. How
do you all who run public-access systems protect yourselves against this
kind of thing? If it went on for long enough, the person could get
himself an entire OS for free!!
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 ...
Anyone else have any ideas on this? How do you all deal with this?
Bill
--
Work: heiser@tdw201.ed.ray.com
{decuac,necntc,uunet}!rayssd!tdw201!heiser
Home(1): bill%unixland.uucp@world.std.com -or- uunet!world!unixland!bill
Public Access Unix Coming Soon!
Home(2): Bill.Heiser@f240.n322.z1.fidonet.org (BBS: 1-508-655-3848)
Other: heiser@world.std.com (Pub. Access Unix)mpd@anomaly.sbs.com (Michael P. Deignan) (09/13/90)
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. Since I'm getting >ready to set up my system for public access, this concerns me. How >do you all who run public-access systems protect yourselves against this >kind of thing? If it went on for long enough, the person could get >himself an entire OS for free!! Well, getting an entire OS for free is a bit far-fetched for a user to accomplish, since there is a little more to the installation process than merely copying files off a floppy disk onto a hard drive. I don't mind shell users downloading binaries, and long as they are from "freeware" type packages, like ELM, GCC, etc. I get upset when I see someone downloading my /bin/sh (which, with the proper patches to the binary and re-uploaded might become a formidable tool for the wrong user) which I purchased, and subsequently puts me in violation of my license agreement. Of course, if someone said to me: "Hey, I just trashed my /bin/csh, mind if I download yours?" and I know they have the same OS that I do, then I don't mind too much (although, technically I suppose that too is a violation of the same license agreement...) >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 ... This is one way to prevent the problem from happening, albeit a bit difficult for legitimate shell users to grapple with. I find it is merely easier to trust someone until they give me reason not to. Of course, another *NIX user, with 'CU', could still '%get' a file from your system! Right now, as I'm starting the process of getting a second modem installed for our system, is wondering how I'm going to prevent shell users from '<insert-your-favorite-comm-program-here>'ing off on my second line to BBS's in the UK! MD MD -- -- Michael P. Deignan, President -- Small Business Systems, Inc. -- -- Domain: mpd@anomaly.sbs.com -- Box 17220, Esmond, RI 02917 -- -- UUCP: ...uunet!rayssd!anomaly!mpd -- Telebit: +1 401 455 0347 -- -- XENIX Archives: login: xxcp, password: xenix Index: ~/SOFTLIST --
ralphs@halcyon.wa.com (Ralph Sims) (09/13/90)
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. Since I'm getting Sounds like he left HIMSELF open. > 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). > Anyone else have any ideas on this? How do you all deal with this? Watch your back. Protect your files. Don't give shell users root access. Run an MS-DOS system. -- Remember when dethroning idols to save the pedestals--they may come in handy...
mikey@quiche.cs.mcgill.ca (Michael GALLOP) (09/13/90)
In article <iPZeP1w163w@halcyon.wa.com> 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. Since I'm getting Fat lot of good that would do joe user. Remember, first off that this is not the DOS world. Those binaries aren't portable. What runs on a SUN has trouble running on other SUNs. So I don't think the kid who downloads /usr/bin is going to have much use for them. Now if it is and i386 UNIX maybe they might be useful >> 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. Exactly, what you can do is: chmod 711 /usr/bin/* Which produces (I think :-)) rwx--x--x on every file in /usr/bin >> Anyone else have any ideas on this? How do you all deal with this? Further, any file they may download is useless (see above :-)) But also the files they need to export them to another system, are, by default locked. I.e. /usr/sys/conf on SYSV and /usr/Sun4/sys/conf/MachineName on SunOs. Without those well... While I'm rambling, even if those directories are open, just about all machine these days is sold with UNIX Manuals and support so.... I guess to deal with this, you could hack a copy of rsh, make sure your users aren't root and put a filter in when you compile sz have it get the current directory and then if it is in /usr or /lib or /etc and not tmp then abort..... -- | mikey@quiche.cs.mcgill.ca | Mike Gallop | |"Stealing from one author is plagarism....Stealing from many is research" | I shall walk through the valley of Death and I shall fear no evil....... ..Except, perhaps, a sadistics assignment
jgd@rsiatl.UUCP (John G. DeArmond) (09/13/90)
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. >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. The answer is in your post. We have none of that problem here. Of course, we choose our users fairly carefully and have in place a first-offense-termination rule. Even if you you removed all file transfer programs and the development tools, it would only take an experienced Unix programmer a little while to hack together an elementary transfer program using awk, sed, ed or any of a number of other tools. Technology will never solve problems of inferior ethics. A method of self-policing in regards to the quality of articles posted from this site might work for you. We have a pretty liberal posting policy and rely primarily on peer pressure for quality control. One mechanism is that we have a local newsgroup, rsi.postings, that receives a copy of all locally posted articles. The knowledge that everybody on the system sees all posts regardless of the original newsgroup is sufficient peer pressure that we've never had a problem. You could probably do something similiar by hacking the source to sz and kermit to post the name of the user and the name of the file transfered to a local newsgroup. One other thing we have is a custom-written getty that logs all keystrokes received during the login process to an external device via a physically one-way path. This is designed to alert us to users who would play around with password guessing and/or crackers who try the system. We make the existence of this system very public which serves as a deterrent. I firmly believe that if one removes the barriers to a system that represent challenges, the incentive to misbehave is removed for most people. And you simply eliminate the small subset that do misbehave. If you really wanted to try a technology solution, one would be to carefully restrict the permissions on binaries to execute-only. I say "carefully" because you may break a number of scripts that rely on being able to test the readability of files to verify their existence. John -- John De Armond, WD4OQC | We can no more blame our loss of freedom on congress Radiation Systems, Inc. | than we can prostitution on pimps. Both simply Atlanta, Ga | provide broker services for their customers. {emory,uunet}!rsiatl!jgd| - Dr. W Williams | **I am the NRA**
epeterso@encore.com (Eric Peterson) (09/13/90)
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.
heiser@tdw201.ed.ray.com (09/13/90)
Thanks to all of you who replied so quickly to my question about
protecting my system against unauthorized downloads of binary files.
The overwhelming majority of the responses have told me what I
already knew -- the (obvious) setting of file modes to be execute-only.
Several people also suggested making the system avaialble only
via a BBS mode. The remainder basically felt that I shouldn't worry
about this, as it wouldn't really be feasible for someone to build
an entire OS in this manner.
I guess the bottom line is just to make most of the stuff execute-
only, not worry about the rest, and to keep track of who you give
shell access to.
Unless anyone has any new "magic" to share, there's no need to send
any more replies to that message ... Thanks again for all your
responses.
Bill
--
Work: heiser@tdw201.ed.ray.com
{decuac,necntc,uunet}!rayssd!tdw201!heiser
Home(1): bill%unixland.uucp@world.std.com -or- uunet!world!unixland!bill
Public Access Unix Coming Soon!
Home(2): Bill.Heiser@f240.n322.z1.fidonet.org (BBS: 1-508-655-3848)
Other: heiser@world.std.com (Pub. Access Unix)zeleznik@cs.utah.edu (Mike Zeleznik) (09/13/90)
In article <epeterso.653228040@houligan> epeterson@encore.com writes: >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. >| > [ lots deleted ...] > >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. Can't this be circumvented by the user first copying the files to their own directory, making them owned by the user. Now they are valid for export. And if you try and change all the possible ways to copy a file, such that the above checks are made, the user can still load their own copy program to do it for them, since it doesn't have to run in any priv mode. Mike Michael Zeleznik Computer Science Dept. University of Utah zeleznik@cs.utah.edu Salt Lake City, UT 84112 (801) 581-5617
karl@naitc.uucp (Karl Denninger) (09/13/90)
In article <22@tdw205.ed.ray.com> 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. Since I'm getting >ready to set up my system for public access, this concerns me. How >do you all who run public-access systems protect yourselves against this >kind of thing? If it went on for long enough, the person could get >himself an entire OS for free!! > >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 ... > >Anyone else have any ideas on this? How do you all deal with this? Easy. Remove read access for everyone other than root on all the system executables and files. Now you can't download the files, since you can't open them for read access. MOST systems ship with the entire contents of /bin, /usr/bin, and even /etc readable by world! This, needless to say, is complete garbage; there's no reason in the world why someone has to have read access to /bin/cc! I would consider that any manufacturer who does this is at least guilty of contributory negligence if their software gets stolen. And the list that I know of includes Microport, AT&T, ISC, SCO, and others. Yep, all the '386 Unix people. Now, if you are so inclined and decide to, you can actually remove read access on all these files. Or you can just let them have 'at it, figuring that the manufacturer wanted them world-readable, since he/she left them that way. -- Karl Denninger AC Nielsen kdenning@ksun.naitc.com (708) 317-3285 Disclaimer: Contents represent opinions of the author; I do not speak for AC Nielsen on Usenet.
john@jwt.UUCP (John Temples) (09/14/90)
In article <3952@quiche.cs.mcgill.ca> mikey@quiche.cs.mcgill.ca (Michael GALLOP) writes: >Exactly, what you can do is: >chmod 711 /usr/bin/* >Which produces (I think :-)) rwx--x--x on every file in /usr/bin This fails on things like 286 binaries that you have to have read permission in order to execute on System V/386. I don't understand why there's any reason to be concerned about this, anyway. Why should the sysop be held responsible for theft by others? This seems no different than someone sneaking into my office when I'm not there and stealing a piece of copyrighted software. It would be like the police arresting ME after my house got robbed, saying it was my fault for leaving the door unlocked! Perhaps a signon message like "anything that is not in /usr/local should be assumed to be copyrighted and not available for download" would be adequate. As long as the sysop is not promoting theft ("Welcome new users! FREE UNIX operating system programs here for the downloading!"), I can't imagine the copyright police being able to hold anything against you. -- John W. Temples -- john@jwt.UUCP (uunet!jwt!john)
gwhisen@neutrino.urbana.mcd.mot.com (Gary Whisenhunt) (09/14/90)
In article <22@tdw205.ed.ray.com>, 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. Since I'm getting |> ready to set up my system for public access, this concerns me. How |> do you all who run public-access systems protect yourselves against this |> kind of thing? If it went on for long enough, the person could get |> himself an entire OS for free!! |> |> 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 ... |> |> Anyone else have any ideas on this? How do you all deal with this? Change the mode of the binaries that you want to protect to: -r-x--x--x (assuming that they people using this are not the owners of the binaries which they shouldn't be) so that people can execute them but can't read them. You also need to ensure that you can't ptrace one of these executables, otherwise you can very slowly make copies of the executing images. I can't really remember which variants of UNIX closed this door. Gary Whisenhunt Motorola Inc., MCD - Urbana gwhisen@urbana.mcd.mot.com 1101 E. University Avenue ..!uiucdcs!udc!gwhisen Urbana, IL 61801
larry@nstar.uucp (Larry Snyder) (09/14/90)
heiser@sud509.ed.ray.com (Bill Heiser - Unix Sys Admin) writes: >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 here at nstar, there are no shell accounts except for mine.. -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, uunet!sco!romed!nstar!larry, nstar!larry@ndmath.math.nd.edu} regional UUCP mapping coordinator Public Access Unix Site (219) 289-0282 (5 high speed lines)
mju@mudos.ann-arbor.mi.us (Marc Unangst) (09/14/90)
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. (However, note that something like "chmod 711 /usr/bin/*" is a Bad Idea, since it strips things like SUID and SGID bits. Try "chmod go-rw /usr/bin/*" instead.) > 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. 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: % cd % mkdir etc % cd etc % cat >passwd root::0:0::/:/bin/sh ^D % su root Password: <return> # 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). 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. Forget about hacking sz(1) or rz(1), because the user can just upload their own version, compile it, and use it. -- Marc Unangst | "da-DE-DA: I am sorry, the country you have mju@mudos.ann-arbor.mi.us | dialed is not in service. Please check the ...!umich!leebai!mudos!mju | number and try again." -- Telecom Kuwait
jdc@naucse.cse.nau.edu (John Campbell) (09/14/90)
> > MOST systems ship with the entire contents of /bin, /usr/bin, and even /etc > readable by world! This, needless to say, is complete garbage; there's no > reason in the world why someone has to have read access to /bin/cc! I disagree. Read access to /bin/cc (or /bin/ccp) is often the only way I have to find out what preprocessor strings are defined. In fact, there was a shell script posted to comp.unix.questions to help us who were looking for a way to distinguish between vax, unix, m6800, and other cc compilers. Many vendors ship the same man page for cc they received from ATT even though they wrote a new compiler. Unfortunately the best information (short of the source code) is not in the manual but in ``string /bin/cc''. I know a pascal class I taught on unix would have flubbed if I couldn't have found out a bit more about the compiler by using the ``string'' function. Another case of security and functionality conflicting? -- John Campbell jdc@naucse.cse.nau.edu CAMPBELL@NAUVAX.bitnet unix? Sure send me a dozen, all different colors.
craigb@ips.oz.au (Craig Bevins) (09/14/90)
In article <22@tdw205.ed.ray.com> 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. Since I'm getting >ready to set up my system for public access, this concerns me. How >do you all who run public-access systems protect yourselves against this >kind of thing? If it went on for long enough, the person could get >himself an entire OS for free!! It's one thing to have the binaries, but how do you bootstrap them? With time-charged calls, it seems like a pretty expensive way to get yourself a Unix distribution anyway. I have been involved for many years with a public access Unix system where *everybody* has full shell access. I have seen some incredibly stupid and anti-social shenanigans in my time, but never anybody trying to download a free copy of Unix. And we don't have time-charged local calls here in Oz, so it would be a much less expensive proposition. Maybe this person was just a dick-head? >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 ... If your biggest problem with a public access system is that somebody might rip off a few binaries, then you're miles in front of most of the rest of us. If this is really a concern, though, what's wrong with turning off the "other" read bits (i.e. "chmod o-r")? Make sure you don't touch shell scripts, though. csb
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (09/14/90)
In article <2412@sud509.ed.ray.com> heiser@tdw201.ed.ray.com writes: > Thanks to all of you who replied so quickly to my question about > protecting my system against unauthorized downloads of binary files. > The overwhelming majority of the responses have told me what I > already knew -- the (obvious) setting of file modes to be execute-only. And what do you do about text images in core files? To do this right, you should protect all your executables and scripts behind a setuid program that handles access control and disables the appropriate signals. ---Dan
sralston@srwic.UUCP (Steve Ralston) (09/14/90)
In article <3952@quiche.cs.mcgill.ca> mikey@quiche.cs.mcgill.ca (Michael GALLOP) writes: >Exactly, what you can do is: >chmod 711 /usr/bin/* >Which produces (I think :-)) rwx--x--x on every file in /usr/bin I would NOT recommend that anyone execute the above command on their **IX system. Reason: You will break most every program that relies on SETUID and/or SETGID permissions. Unless you KNOW (or have recorded) the default permissions [anywhere on your system], running that kind of chmod command could cost you much effort to undo. Much better would be: chmod o-r /usr/bin/* # revoke read permission from "others" # (other than user (owner) or group) but then, hardly any of the programs in /usr/bin should have "other read" perms set by DEFAULT anyway; unless you're running a fairly non-secure system. -- Steve Ralston sralston@srwic.UUCP 235 N Zelta voice: 316-686-2019 Wichita, KS 67206 ..!uunet!ncrlnk!ncrwic!srwic!sralston
epeterso@encore.com (Eric Peterson) (09/14/90)
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.
bruce@segue.segue.com (Bruce Adler) (09/15/90)
In article <7772:Sep1408:18:1190@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >And what do you do about text images in core files? Although I'm not familiar with every Unix implementation, the ones I've seen don't include the text segment in a core file. The exception to this rule is if you've specially linked your load module to place all of the program text in the data segment (i.e. non-split I+D). This is usually only done when you've a need to modify the text while the program is executing via a debugger. But commercial products aren't usually shipped as non-split I+D load modules. Core files also don't usually include shared libraries, shared memory segments, and/or memory mapped files. -- bruce@segue.com ism.isc.com!segue!bruce aero.org!segue!bruce -- bruce@segue.com ism.isc.com!segue!bruce aero.org!segue!bruce
irv@happym.wa.com (Irving Wolfe [h]) (09/15/90)
In <2412@sud509.ed.ray.com> heiser@tdw201.ed.ray.com writes: >Unless anyone has any new "magic" to share, there's no need to send >any more replies to that message ... Thanks again for all your >responses. Maybe there's one thing more. This whole question and response thing was a silly waste. UNIX is understood to be a multi-user system. If the vendor distributes files world-readable, then the vendor is responsible for what happens to them and you are not. If, of course, you changed the default permissions on the files, you might be in a more exposed position, but why on earth would you have done that? Assuming you didn't, maybe the answer is to not watch the users so closely, to keep your nose out of other people's activities, and to treat your fellow humans to a new, more relaxed, accepting, respectful, and friendly Bill. And if you really feel someone on your system is a creep, kick him the hell off! -- Irving Wolfe Happy Man Corp. irv@happym.wa.com 206/463-9399 ext.101 4410 SW Point Robinson Road, Vashon Island, WA 98070-7399 fax ext.116 SOLID VALUE, the investment letter for Benj. Graham's intelligent investors Information free (sample $10 check or credit card): email patty@happym.wa.com
les@chinet.chi.il.us (Leslie Mikesell) (09/15/90)
In article <7772:Sep1408:18:1190@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >To do this right, you should protect all your executables and scripts >behind a setuid program that handles access control and disables the >appropriate signals. Yes, and the vendor-supplied login program does exactly that. If it allows all users to read the executables as supplied by the vendor, then we should assume that the vendor either doesn't care if they are copied or is negligent in their responsibilities. Les Mikesell les@chinet.chi.il.us
dylan@ibmpcug.co.uk (Matthew Farwell) (09/15/90)
In article <epeterso.653316195@houligan> epeterson@encore.com writes: >mju@mudos.ann-arbor.mi.us (Marc Unangst) writes: >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. Actually 2+1/2. Don't link /etc/passwd to <chroot dir>/etc/passwd. Maintain a separate copy of the passwd file in the chroot dir, with passwds starred out. Its easy enuf to do. Just have a script something like:- awk -F: '{ OFS=":" ; print $1,"*",$3,$4,$5,$6,$7 }' /etc/passwd > whatever (forgive me if my awk isn't up to scratch) Only problem I can see with this approach is that the user can't (easily) change his/her/its password. All depends on the time + effort you want to put into security. Dylan. -- Matthew J Farwell | Email: dylan@ibmpcug.co.uk The IBM PC User Group, PO Box 360,| dylan%ibmpcug.CO.UK@ukc Harrow HA1 4LQ England | ...!uunet!ukc!ibmpcug.co.uk!dylan Phone: +44 81-863-1191 | Sun? Don't they make coffee machines?
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (09/16/90)
In article <epeterso.653228040@houligan> epeterson@encore.com 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. Whatever gave you the idea that people need to read the kernel? All my files are are protected against user reading, and I haven't seen any problems. If people want to read the kernel let them buy their own systems! I've been running since May 1986, so I have some reasonable experience on the topic. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (09/17/90)
In article <1990Sep14.034306.16283@ips.oz.au> craigb@ips.oz.au (Craig Bevins) writes: | It's one thing to have the binaries, but how do you bootstrap them? | With time-charged calls, it seems like a pretty expensive way to get | yourself a Unix distribution anyway. Probably true, but it is a cheap way to upgrade from the two user system to multiuser with development set and text, plus any third party programs around. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (09/17/90)
In article <epeterso.653316195@houligan> epeterson@encore.com writes: | 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. Helpful to whom? It is not helpful to me to have any user do these things. If there are programs which must read the kernel, after they are debugged using dummy copies they can be setgid kmem (or sysinfo in SysV) to allow access. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
der@anomaly.sbs.com (Admiral David Edward Ryan) (09/17/90)
In article <1990Sep13.194016.2142@nstar.uucp> larry@nstar.uucp (Larry Snyder) writes: > >here at nstar, there are no shell accounts except for mine.. > Gee, Larry, now there is some real useful advice. Why is it every response from you has a "Hey, here's an attempt to plug my BBS" ring to it? Ask us if we really *care* whether or not you have shell accounts on your system, since obviously the question dealt with preventing *shell users* from downloading distribution software. Take it to alt.bbs.ads, or better yet, alt.dev.null. David -- -- Admiral David E. Ryan -- der@anomaly.sbs.com -- ...!uunet!rayssd!anomaly!der -- -- Admiral David E. Ryan -- der@anomaly.sbs.com -- ...!uunet!rayssd!anomaly!der
heiser@tdw201.ed.ray.com (09/17/90)
In article <epeterso.653228040@houligan> epeterson@encore.com writes: > >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. This sounds like an interesting idea. I'll have to give it some thought. >There is also a command under System V called "chroot". What that Another interesting idea. Maybe building a "mini file system", and chrooting to it for remote shell users would give them the stuff they need, yet protect me. >| 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? > I run an MSDOS system now -- that's EXACTLY what I'm trying to get away from! No sysop in their right mind would give any dos bbs users shell access! There is NO security whatsoever under msdos... -- Work: heiser@tdw201.ed.ray.com {decuac,necntc,uunet}!rayssd!tdw201!heiser Home(1): bill%unixland.uucp@world.std.com -or- uunet!world!unixland!bill Public Access Unix Coming Soon! Home(2): Bill.Heiser@f240.n322.z1.fidonet.org (BBS: 1-508-655-3848) Other: heiser@world.std.com (Pub. Access Unix)
heiser@tdw201.ed.ray.com (09/17/90)
In article <1990Sep14.034306.16283@ips.oz.au> craigb@ips.oz.au (Craig Bevins) writes: > >If your biggest problem with a public access system is that somebody >might rip off a few binaries, then you're miles in front of most of What other problems have you had (or you watch for)? -- Work: heiser@tdw201.ed.ray.com {decuac,necntc,uunet}!rayssd!tdw201!heiser Home(1): bill%unixland.uucp@world.std.com -or- uunet!world!unixland!bill Public Access Unix Coming Soon! Home(2): Bill.Heiser@f240.n322.z1.fidonet.org (BBS: 1-508-655-3848) Other: heiser@world.std.com (Pub. Access Unix)
heiser@tdw201.ed.ray.com (09/17/90)
In article <epeterso.653316195@houligan> epeterson@encore.com writes: > >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? What's a "public access unix" without shell access? I want to provide access for all of the reasons you mentioned here. If I wanted to continue to ONLY allow access via a menu-driven program, I'd have no reason to switch from my current dos bbs. bill -- Work: heiser@tdw201.ed.ray.com {decuac,necntc,uunet}!rayssd!tdw201!heiser Home(1): bill%unixland.uucp@world.std.com -or- uunet!world!unixland!bill Public Access Unix Coming Soon! Home(2): Bill.Heiser@f240.n322.z1.fidonet.org (BBS: 1-508-655-3848) Other: heiser@world.std.com (Pub. Access Unix)
atman@csuchico.edu (Homeless hacker) (09/18/90)
In article <2441@sud509.ed.ray.com> heiser@tdw201.ed.ray.com writes: >What's a "public access unix" without shell access? I want to provide >access for all of the reasons you mentioned here. If I wanted to >continue to ONLY allow access via a menu-driven program, I'd have no >reason to switch from my current dos bbs. What about all those neat (multiuser) games available for Unix that won't run under dos? Cf Empire, conquer, mazewar, etc? Or have these been translated to run under Desqview or some other similar multi-tasker? (Not to mention wumpus and fortune! :-) ) -- ------ reply to atman%csuchico.EDU@RELAY.CS.NET or one of these others: Fidonet : atman via 1:119/666.0 WWIVnet : 1@9651
richard@pegasus.com (Richard Foulk) (09/18/90)
> >here at nstar, there are no shell accounts except for mine.. > Bummer. -- Richard Foulk richard@pegasus.com
grant (Grant DeLorean) (09/18/90)
heiser@tdw201.ed.ray.com writes: > I run an MSDOS system now -- that's EXACTLY what I'm trying to get away > from! No sysop in their right mind would give any dos bbs users shell > access! There is NO security whatsoever under msdos... Someone has to say it... There is barely a shell with MS-DOS to give access to. Command.com always has been and still is pretty pathetic. Oooops, this isn't an alt.flame.mickeysoft group, so I better stop now... ;-] Do yourself a favor, go right on up to Unix. I resisted it for a while myself (took an interesting sidetrack that went nowhere on the way to Unix) but am right now extremely happy I went to Unix. Switching my BBS to Waffle took a couple of days to get used to (Waffle can be pretty off the wall) but Unix is worth it. Since I came from QNX to Unix I also got the advantage of getting a real NetHack (3.0i yet :-)) but that is another subject (but an addicting one). Grant DeLorean ...osu-cis!n8emr!bluemoon!grant ...towers!bluemoon!grant (614) 868-9982 HST & V.32 Blue Moon BBS, a public access Unix BBS (614) 868-9984 PEP & V.32 ++Being self employed, my opinions are remarkably similar to my employers.
pizzi@esacs.UUCP (Riccardo Pizzi) (09/18/90)
In article <2441@sud509.ed.ray.com>, heiser@tdw201.ed.ray.com writes: > What's a "public access unix" without shell access? I want to provide > access for all of the reasons you mentioned here. If I wanted to > continue to ONLY allow access via a menu-driven program, I'd have no > reason to switch from my current dos bbs. I do not agree. I used to run a DOS BBS for about 1 year and had a lot of troubles with that dozen of third-party programs that are needed to setup a good dos bbs that is fidomail-capable. There are a *lot* of reasons to switch to a unix bbs, for example if you run more than one access line, or if you don't want to devote 100% of your machine to the bbs users. (Yes, I know that there are plenty of dos multitaskers out, but they would just multiply your troubles). I am now writing my own software, and I plan to distribute it when it's ready. Everybody can take a look at it by calling 0039-541-27858 (Telebit) or 0039-541-27135 (USR HST). The program is news & fido-compatible and has a lot of nice features, but sorry, it is not ready yet. If somebody would like to get some info on the software's capabilities, drop me a line and I'll post a message here. Ciao Rick, ITALY -- Riccardo Pizzi @ ESA Software srl - ITALY uunet: ....mcsun!i2unix!esacs!pizzi voice: (0039) 541 741113 fax: (0039) 541 742153 UnixBBS: (0039) 541 27858 PEP
larry@nstar.uucp (Larry Snyder) (09/18/90)
heiser@tdw201.ed.ray.com writes: >What's a "public access unix" without shell access? I want to provide >access for all of the reasons you mentioned here. If I wanted to >continue to ONLY allow access via a menu-driven program, I'd have no >reason to switch from my current dos bbs. come now - with unix (running waffle) you can spawn anything - one user can be in wordperfect, while another in foxbase, etc. Waffle makes it very easy to spawn applications by users - yet maintains system security. shell access can be risky - we have no shell access here at nstar, and for security reasons we intend to keep it that way. there are lots of reasons to switch from (what was that OS, D0S?) - get serious -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, uunet!sco!romed!nstar!larry, nstar!larry@ndmath.math.nd.edu} usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
heiser@tdw201.ed.ray.com (09/19/90)
>What about all those neat (multiuser) games available for Unix that >won't run under dos? Cf Empire, conquer, mazewar, etc? Or have >these been translated to run under Desqview or some other similar >multi-tasker? > >(Not to mention wumpus and fortune! :-) ) Well, those are probably good reasons to run unix and allow shell access too! (I was arguing FOR shell access, not against it). I haven't tried any of those games (or any unix games for that matter, other than what came with SunOS and we deleted). None came with my Esix system. -- Work: heiser@tdw201.ed.ray.com {decuac,necntc,uunet}!rayssd!tdw201!heiser Home(1): bill%unixland.uucp@world.std.com -or- uunet!world!unixland!bill Public Access Unix Coming Soon! Home(2): Bill.Heiser@f240.n322.z1.fidonet.org (BBS: 1-508-655-3848) Other: heiser@world.std.com (Pub. Access Unix)
karl@naitc.naitc.com (Karl Denninger) (09/20/90)
In article <1990Sep18.120450.14590@nstar.uucp> larry@nstar.uucp (Larry Snyder) writes: >heiser@tdw201.ed.ray.com writes: > >>What's a "public access unix" without shell access? I want to provide >>access for all of the reasons you mentioned here. If I wanted to >>continue to ONLY allow access via a menu-driven program, I'd have no >>reason to switch from my current dos bbs. > >come now - with unix (running waffle) you can spawn anything - one user >can be in wordperfect, while another in foxbase, etc. Waffle makes it >very easy to spawn applications by users - yet maintains system security. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >shell access can be risky - we have no shell access here at nstar, and >for security reasons we intend to keep it that way. I hope you don't allow "vi" access, or you have the bbs in a "chroot"ed area with no backlinked files (ie: no linked files between the areas). If not, give me the phone number, and I'll have a user shell (ie: bourne shell) in 30 seconds flat after I get "vi" up. I'll send you email from the shell account, or "write" you as sufficient evidence that I was successful. Without source code to "vi" there is NO WAY to prevent this. Believe me. I had this rather graphically illustrated to me once; it's a flaw in the way vi works. There is simply no prevention available if the shell is findable on the system ANYWHERE. This means you need to "chroot" your "open" bbs, or be VERY selective about what you let your users "shell out" to. This is also a great way for people who normally have a "restricted" shell to break out of it. Editors are wonderful, aren't they? This is the reason that AKCS' installation manual specifically recommends against allowing users to use the "vi" editor if they are captive users (there's a file which lists the editors that are available to "bbs" users). The documentation also tells 'ya to make sure your other editors and packages you install as "callable" don't have this hole -- which in most cases means you need the source to same, or a high degree of confidence in the commercial package you're about to let users at. Callable system utilities are a recipe for disaster without EXTREME care in implementation or a chrooted area for the bbs in general. In general, if you want to let people at other facilities, it's best to either write your own facilities, wrappers for same with a chroot in the middle, or chroot the entire BBS system. The wrapper approach has it's own problems, as it has to run SUID root in order to do the chroot, and that's a security risk in and of itself. The only other alternative is to assign individual UNIX LEVEL accounts for all the users, and put their home directories where they can't do any harm (ie: /tmp, or a filesystem you don't care about). The first (ie: /tmp) works IF your BBS keeps all it's indices internally; if it stores them somewhere in the user's directory structure you'll get in real big trouble with this scheme (this won't work with AKCS, for example). Anyone who wants to test this theory can send me their system's phone number. If you're running external stuff you purchased, or utilities that came with the machine, and haven't taken these precautions, there's a good chance I can get a user shell in minutes. -- Karl Denninger AC Nielsen kdenning@ksun.naitc.com (708) 317-3285 Disclaimer: Contents represent opinions of the author; I do not speak for AC Nielsen on Usenet.
bote@csense.uucp (John Boteler) (09/20/90)
From article <2441@sud509.ed.ray.com>, by heiser@tdw201.ed.ray.com: > In article <epeterso.653316195@houligan> epeterson@encore.com writes: >>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 a "public access unix" without shell access? I want to provide > access for all of the reasons you mentioned here. If I wanted to > continue to ONLY allow access via a menu-driven program, I'd have no > reason to switch from my current dos bbs. This sounds like 'Public Administration 101' all over again. Want benefits? Accept risks! -- John Boteler bote@csense.uucp {uunet | ka3ovk}!media!csense!bote SkinnyDipper's Hotline: 703-241-BARE | VOICE only, Touch-Tone(TM) signalling
jbm@celebr.uucp (John B. Milton) (09/21/90)
In article <2412@sud509.ed.ray.com> heiser@tdw201.ed.ray.com writes: >Thanks to all of you who replied so quickly to my question about >protecting my system against unauthorized downloads of binary files. >The overwhelming majority of the responses have told me what I >already knew -- the (obvious) setting of file modes to be execute-only. [lots deleted] Watch out! In addition to execute, you MUST leave +r on all *shell scripts*, or the shell (not the kernel) can't open them to INTERPRET them. This would do it (MUST BE RUN AS ROOT so that set[ug]id bits don't get lost) for d in /etc /bin /usr/bin /usr/local/bin /usr/lbin; do cd $d if [ -f .distperm ]; then echo "Directory $d already read protected" else ls -l > .distperm file * | grep '386 exe' | cut -d: -f1 | while read i; do if [ -x $i ]; then chmod go-r $i fi done fi done (I just typed this in, so DON'T post if I goofed something trivial) The "ls -l > .distperm" creates a file containing the original permissions as distributed. Most everything should still be ok, unless your machine has some bad shell script with "if [ -r /bin/ls ]...". Most shell scripts I've seen do the right thing (-x). Note the trick to find binary executables "386 exe". Do a "file /bin/ls" to make sure "386 exe" is a good substring for your machine. You WILL have to change it if your machine isn't a 386. The files to watch out for would most likely be something in /etc, so you might not want to run it on that directory. Files that may match the executable string from the file command that you CANNOT remove read acccess to are: /unix (lots of programs use nlist(3) on it) and *.[ao]. If you don't NEED to protect your system in this way, DON'T DO IT, you're just in for a lot of headaches. The argument that that there is no need to protect a public system is not entirely valid. Someone may want to download just a package you have that they do not: man pages (which could be protected by setuid man page readers), X (which one would think could be easily obtained freely, but not so because of proprietary servers), DWB (almost always costs extra, a prime target), TCP/IP and compiler (tougher to get all the pieces), comercial packages. One attack method that is easy to use is to look at how a package is installed on the system, find the de-install script and trace it to figure out where all the parts of the package are. These scripts are easily protected since they are only used by root to de-install a package. The chroot(2)(1) idea is a very powerful one, but a bitch to setup and maintain (/etc/[uw]tmp, /usr/mail, news). It is also easy for a user to figure out that they are in a chroot environment (ls -lid /). The rsh idea only works with beginners and should NEVER be relied upon. Pseudo shells, menus and BBSs are one of the best ways to provide access in a secure way, but you have to be VERY careful about running programs that can shell out (rn, vi, mail). Hacking up restricted versions of these programs can be another maintenance hassle. The correct way to hack up these programs is to make sure that they ALWAYS ONLY use the SHELL environment variable. For menu users you point SHELL to something like /bin/false or a program that informs them that they can not shell out. Public source is available to mail programs (MUSH, ELM, etc.), news readers (rn) and editors (mg2a, stevie, etc.) The absolute best way is to restrict your machine to trusted people and avoid the friend of a friend of a friend kind of thing. P.S. Anyone got a quick tool for changing rwxr-s--x stuff to 2751 stuff? John -- John Bly Milton IV, jbm@uncle.UUCP, n8emr!uncle!jbm@osu-cis.cis.ohio-state.edu (614) h:252-8544, w:469-1990; N8KSN, AMPR: 44.70.0.52; Don't FLAME, inform!
les@chinet.chi.il.us (Leslie Mikesell) (09/22/90)
In article <1990Sep20.153105.28394@naitc.naitc.com> karl@bbs.naitc.com (Karl Denninger) writes: >I hope you don't allow "vi" access, or you have the bbs in a "chroot"ed area >with no backlinked files (ie: no linked files between the areas). What is the danger of linked files if the users don't have write permssion to any of them? It takes a non-trivial amount of baggage to make vi happy (at least on modern SysV it wants the shared libs, all of /usr/lib/terminfo/*/*, TMPDIR, plus the shell and whatever tools you need for paragraph reformatting, sorting and the like). Too bad we don't have read-only symlinks. >Without source code to "vi" there is NO WAY to prevent this. Believe me. >I had this rather graphically illustrated to me once; it's a flaw in the >way vi works. Actually it's a feature of the way unix works - all the tools expect to be able to include all the others. Les Mikesell les@chinet.chi.il.us
bote@csense.uucp (John Boteler) (09/23/90)
Posting for the benefit of the trustee: >Message-Id: <9009222103.AA06890@scicom.alphacdc.com> >Date: 22 Sep 90 21:03:45 MDT (Sat) >From: uunet!scicom.alphacdc.com!rick (Richard E. Oakes) >Status: RO > From article <2441@sud509.ed.ray.com>, by heiser@tdw201.ed.ray.com: > > In article <epeterso.653316195@houligan> epeterson@encore.com writes: > >>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 a "public access unix" without shell access? I want to provide > > access for all of the reasons you mentioned here. If I wanted to > > continue to ONLY allow access via a menu-driven program, I'd have no > > reason to switch from my current dos bbs. I came into this discussion a little late, but so far I have seen no discussion of the oldest, but still effective way of controlling what users do once they get to the shell: the use of /bin/rsh. rsh does not let the user cd to other directories, or execute commands with a path in the command (paths ARE allowed in the arguments), so you can controll exactly which commands they can execute. To implement this properly, you do need to remember a few things: The .profile of the user must be owned by root, and writeable ONLY by root. The .profile must define a PATH that includes a directory such as /rbin, and does NOT include /bin or /usr/bin. The .profile must define and export SHELL=/usr/rbin. This will ensure that any shell called from vi or other programs are also rsh. When you create the /rbin or similar directory, you ln any commands from /bin and /usr/bin that you wish the user to have unlimited access to (or even from /usr/local, /usr/lbin, etc). If you want to allow limited acces, such as testing the arguments before allowing exeuction of the command, you can write a shell script in /rbin that performs your test, then calls the command from /bin. For example, you might want to allow execution of the 'cat' command, but not allow reading of any file in /, /etc, /bin, or /usr/bin. You write a shell script called /rbin/cat that tests its arguments, and if they include any of the prohibited paths, send as error message to the user, and if not, passes the argument to /usr/bin/cat. Richard Oakes -- John Boteler bote@csense.uucp {uunet | ka3ovk}!media!csense!bote SkinnyDipper's Hotline: 703-241-BARE | VOICE only, Touch-Tone(TM) signalling
karl@naitc.naitc.com (Karl Denninger) (09/24/90)
In article <1990Sep22.024446.3305@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <1990Sep20.153105.28394@naitc.naitc.com> karl@bbs.naitc.com (Karl Denninger) writes: > >>I hope you don't allow "vi" access, or you have the bbs in a "chroot"ed area >>with no backlinked files (ie: no linked files between the areas). > >What is the danger of linked files if the users don't have write permssion >to any of them? It takes a non-trivial amount of baggage to make vi >happy (at least on modern SysV it wants the shared libs, all of >/usr/lib/terminfo/*/*, TMPDIR, plus the shell and whatever tools you >need for paragraph reformatting, sorting and the like). Too bad we >don't have read-only symlinks. Because if the user gets root in the subshell, he can then modify the "read only" files and possibly gain access to the main system area. The most graphic example of this is if you are foolish enough to link /etc/passwd (and /etc/shadow for those systems who use it) into the chrooted area. That is as good as not having the chroot in there at all! Anyone who gets root in the chrooted area now can change the password file in the MAIN system area, and thus break in with ease. >>Without source code to "vi" there is NO WAY to prevent this. Believe me. >>I had this rather graphically illustrated to me once; it's a flaw in the >>way vi works. > >Actually it's a feature of the way unix works - all the tools expect to >be able to include all the others. Yeah, some feature. It subverts the restricted shell instantly, and isn't well documented in the "Bugs" section of the manual (I believe that any tool which has this kind of property ought to make note of it in the manual pages at a minimum!) Most people are unaware of the consequences of this "feature" and a number have gotten caught by it over the years. -- Karl Denninger AC Nielsen kdenning@ksun.naitc.com (708) 317-3285 Disclaimer: Contents represent opinions of the author; I do not speak for AC Nielsen on Usenet.
karl@naitc.naitc.com (Karl Denninger) (09/24/90)
In article <1990Sep23.061854.309@csense.uucp> bote@csense.uucp (John Boteler) writes: >Posting for the benefit of the trustee: > >>Message-Id: <9009222103.AA06890@scicom.alphacdc.com> >>Date: 22 Sep 90 21:03:45 MDT (Sat) >>From: uunet!scicom.alphacdc.com!rick (Richard E. Oakes) >>Status: RO > >I came into this discussion a little late, but so far I have seen no >discussion of the oldest, but still effective way of controlling what users >do once they get to the shell: the use of /bin/rsh. rsh does not let the user >cd to other directories, or execute commands with a path in the command (paths >ARE allowed in the arguments), so you can controll exactly which commands they >can execute. To implement this properly, you do need to remember a few things: > > The .profile of the user must be owned by root, and writeable ONLY by > root. > The .profile must define a PATH that includes a directory such as > /rbin, and does NOT include /bin or /usr/bin. > The .profile must define and export SHELL=/usr/rbin. This will ensure > that any shell called from vi or other programs are also rsh. NO! This isn't going to work. Look at ":set shell" again in vi. Try it in this environment. I can get out of any environment that is controlled by "rsh" using this. Vi has a couple of "wonderful" features in it that don't lend themselves to security. ":set shell" is the worst offender of all; for the user who knows how it's a way to get to >any< executable for which the user has execute permission. Yes, I did say "any", and I'll stand by it. To AT&T's credit, they don't claim that "rsh" is completely secure. In fact, if vi (or ex) is on the system, you may as well not bother with "restricted" shell users. -- Karl Denninger AC Nielsen kdenning@ksun.naitc.com (708) 317-3285 Disclaimer: Contents represent opinions of the author; I do not speak for AC Nielsen on Usenet.
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (09/24/90)
In article <1990Sep23.061854.309@csense.uucp> bote@csense.uucp (John Boteler) writes: | The .profile of the user must be owned by root, and writeable ONLY by | root. Overkill. As long as the profile is not writable by the user, it doesn't have to be owned by a special id (one more potential hole). Someone like 'usradmin' would be nice. | The .profile must define a PATH that includes a directory such as | /rbin, and does NOT include /bin or /usr/bin. This is useful but doesn't stop explicit /bin/sh (or whatever) unless /bin just isn't there. ie. chroot. And the PATH better be readonly, a feature of ksh and recent SysV shells. | The .profile must define and export SHELL=/usr/rbin. This will ensure | that any shell called from vi or other programs are also rsh. Assuming they use that convention. Alas too many editors have /bin/sh wired in rather than use the system() call. Microemacs disables shell escapes completely in restricted mode, which is a good reason to offer it instead of vi (depending on how well your vi behaves). I prefer to offer guest users a menu program, which drives from a menu which can be customized for them. Much tighter control than ever letting them have shell access. If you have the disk you can provide shell access in a chroot area and be safe. If you don't have enough disk to copy rather than link, you might still be in trouble. -- bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen) sysop *IX BBS and Public Access UNIX moderator of comp.binaries.ibm.pc and 80386 mailing list "Stupidity, like virtue, is its own reward" -me
brad@looking.on.ca (Brad Templeton) (09/25/90)
If a user gets superuser access while under chroot, you have lost system security. Don't go under the illusion that just your linked files are at risk. Any user with root access can (with or without linker or C compiler access -- all they need is upload access) issue the 'mknod' system call. With mknod you can create raw hard disk devices with write perms. And get access to all the hard disks. Including the main system password file, etc. One can also create a memory device, and (if really clever) 'undo' the chroot call, to be full superuser. Complete system takeover. chroot security is good, but it depends on the user never getting to be root. This means that: a) (fakeroot)/etc and files under it have proper, safe permissions. Double that by simply not allowing programs that do things there, including passwd and chfn etc. This restricts the users a bit, of course. b) Never, never go into the secure subsystem and run programs left there by users while you are root, or any trusted user not chrooted. c) No system program that is root or another trusted user should execute a program from the subsystem. -- Brad Templeton, ClariNet Communications Corp. -- Waterloo, Ontario 519/884-7473
dylan@ibmpcug.co.uk (Matthew Farwell) (09/25/90)
In article <1990Sep24.153529.8627@naitc.naitc.com> karl@bbs.naitc.com (Karl Denninger) writes: In our bbs, we have a chrooted environment. Our passwd file in the chrooted environment is a copy (with all passwords starred out, all directories as /tmp and all shells as /bin/sorry (a c proggy which prints out 'No shell available'). There are a few files which are linked upwards. 2 are ascii messages which are catted (and only catted), and there are the ttys. These need to be linked upwards to allow permissions to be transmitted when the user enters chrooted environment. This could be done by chmodding when they enter, but its far easier this way. People are only in the chrooted environment when they are 1) Editing (not having the source to vi etc.) 2) Downloading (We have got the source to kermit/zmodem, but we want to be sure) Everything else is done in a menu/command line driven environment, which we wrote and we're pretty sure you can't get out of. Can anyone see any problems with this? >>>Without source code to "vi" there is NO WAY to prevent this. Believe me. >>>I had this rather graphically illustrated to me once; it's a flaw in the >>>way vi works. >>Actually it's a feature of the way unix works - all the tools expect to >>be able to include all the others. >Yeah, some feature. It subverts the restricted shell instantly, and isn't >well documented in the "Bugs" section of the manual (I believe that any tool >which has this kind of property ought to make note of it in the manual >pages at a minimum!) Most people are unaware of the consequences of this >"feature" and a number have gotten caught by it over the years. I agree that it is actually a feature. Its a pain when you need to actually take the shell escapes out, but thats true of every editor when you haven't got the source. Look at emacs. How would you restrict that if you didn't have the source? (how could you restrict emacs anyway???) Its not a bug. Its a feature. This article has been written in vi, with judicious use of !}fmt^M. Dylan. -- Matthew J Farwell | Email: dylan@ibmpcug.co.uk The IBM PC User Group, PO Box 360,| ...!uunet!ukc!ibmpcug!dylan Harrow HA1 4LQ England | CONNECT - Usenet Access in the UK!! Phone: +44 81-863-1191 | Sun? Don't they make coffee machines?
frank@rsoft.bc.ca (Frank I. Reiter) (09/26/90)
In article <1990Sep25.122420.9231@ibmpcug.co.uk> dylan@ibmpcug.CO.UK (Matthew Farwell) writes: > >I agree that it is actually a feature. Its a pain when you need to >actually take the shell escapes out, but thats true of every editor when >you haven't got the source. Look at emacs. How would you restrict that >if you didn't have the source? (how could you restrict emacs anyway???) >Its not a bug. Its a feature. Pity there isn't a simple -R (restricted) flag that could be given on the command line. This could prevent shell escapes, and perhaps prevent reading or writing files outside of the current directory. -- _____________________________________________________________________________ Frank I. Reiter UUCP: {uunet,ubc-cs}!van-bc!rsoft!frank Reiter Software Inc. frank@rsoft.bc.ca, a2@mindlink.UUCP Surrey, British Columbia BBS: Mind Link @ (604)576-1214, login as Guest
les@chinet.chi.il.us (Leslie Mikesell) (09/28/90)
In article <1990Sep24.153529.8627@naitc.naitc.com> karl@bbs.naitc.com (Karl Denninger) writes: [re: linked files into chroot area] >Because if the user gets root in the subshell, he can then modify the "read >only" files and possibly gain access to the main system area. The most >graphic example of this is if you are foolish enough to link /etc/passwd >(and /etc/shadow for those systems who use it) into the chrooted area. That >is as good as not having the chroot in there at all! Anyone who gets root >in the chrooted area now can change the password file in the MAIN system >area, and thus break in with ease. I don't have any doubts about the power of root, but is there any reason to think that someone put into a chroot area where there are no suid programs can become root by any means? Les Mikesell les@chinet.chi.il.us
peter@ficc.ferranti.com (Peter da Silva) (09/29/90)
I need to add one more thing to my note on how to protect "vi" and disable shell escapes. If it's linked with a shared library you also need to: copy that library. edit *it* to zap shell escapes. Change the string in the "vi" binay that references it. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` peter@ferranti.com
karl@naitc.naitc.com (Karl Denninger) (10/01/90)
In article <1990Sep27.183258.86@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes: >In article <1990Sep24.153529.8627@naitc.naitc.com> karl@bbs.naitc.com (Karl Denninger) writes: >[re: linked files into chroot area] >>Because if the user gets root in the subshell, he can then modify the "read >>only" files and possibly gain access to the main system area. The most >>graphic example of this is if you are foolish enough to link /etc/passwd >>(and /etc/shadow for those systems who use it) into the chrooted area. That >>is as good as not having the chroot in there at all! Anyone who gets root >>in the chrooted area now can change the password file in the MAIN system >>area, and thus break in with ease. > >I don't have any doubts about the power of root, but is there any reason >to think that someone put into a chroot area where there are no suid >programs can become root by any means? On the surface, I'd say "no". In reality? Well..... are you sure you don't have any device nodes laying around in that area with improper permissions? (this is an easy one for a knowledgable user to exploit). Are you CERTAIN that your OS doesn't have any holes? I know, most people would answer "yes" but is that confidence in design and implementation or just a "bury head in sand" thing? A while ago (when I was in school) we had a DEC-10. Now, for those who aren't in the know about these things, the interface to system calls was rather arcane for assembly programming, and of course the system "traps" took arguments. I discovered, quite by accident, that one particular illegal value for a trap argument would give one full privileges. Imagine that! Yes, I did report the hole, and it was large enough to drive a Mack Truck through. Are you >certain< that your particular version of Unix doesn't have any of these? Witness all the people who have posted about certain opcode combinations (from USER programs now!) crashing RISC machines...... sure, it's not getting root, but it constitutes a denial of service problem. And if there is such a problem in your Unix, and you don't have source, how long do you think it will take to get fixed? -- Karl Denninger AC Nielsen kdenning@ksun.naitc.com (708) 317-3285 Disclaimer: Contents represent opinions of the author; I do not speak for AC Nielsen on Usenet.