conor@Glacier.ARPA (Conor Rafferty) (08/13/85)
A quickie: 4.2BSD chsh does not allow the user to specify alternative shells - only "sh" and "csh" are permitted. Why is this? It seems ironically inappropriate in UNIX, where the shell is ``an ordinary, swappable user program'' and ``user-selectable system interfaces [...] become essentially trivial to implement'' [Ritchie & Thompson CACM 1974]. Conor Rafferty conor@su-glacier.arpa 231A Applied Electronics Lab. conor@su-sierra.arpa Stanford University Ca.94305 decwrl!glacier!conor (415)497-1515
root@bu-cs.UUCP (Barry Shein) (08/14/85)
>From: conor@Glacier.ARPA (Conor Rafferty) >Subject: Alternate Shells >Summary: Why is chsh fascist? >A quickie: 4.2BSD chsh does not allow the user to specify alternative >shells - only "sh" and "csh" are permitted. Why is this? It seems >ironically inappropriate in UNIX, where the shell is ``an ordinary, >swappable user program'' and ``user-selectable system interfaces [...] >become essentially trivial to implement'' [Ritchie & Thompson CACM 1974]. One obvious reason probably had more to do with the 'nuisance' of people setting various things to be their shell and then finding out it was a bad choice and rendering their account useless thus going and bothering some SA to unjam them. Note that chsh was a Berkeley thing and kids will be kids...(it's easy, by the way, to either change or re-write chsh to be more liberal or accept a wider variety of things, but obviously a priv'd account would have to install it.) Note that if you are priv'd I believe chsh lets you set to anything (besides, at that point you don't need chsh.) Another reason that nags the back of my mind is a security hole, but by the time a shell is exec'd for you in login you are already setuid()'d and setgid()'d to you so it doesn't seem to me it opens any hole that isn't already there...hmmm. I think you can see it more as a site policy rather than a restriction imposed by UNIX. Go bug your SA if you have a good argument. Alternatively, you could easily accomplish the same effect through your .login file, just put the command you want right there, no? -Barry Shein, Boston University
chris@umcp-cs.UUCP (Chris Torek) (08/15/85)
We (well, Fred actually) modified chsh to read /lib/ok_shells for a list of the shells "ordinary users" can set up. It's more anti- accidental-stupidity than anything else. I sent the changes back to UCB, so they may be in 4.3... -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
wcs@ho95e.UUCP (x0705) (08/15/85)
> A quickie: 4.2BSD chsh does not allow the user to specify alternative > shells - only "sh" and "csh" are permitted. Why is this? It seems > ironically inappropriate in UNIX, where the shell is ``an ordinary, .... > Conor Rafferty conor@su-glacier.arpa It's especially annoying if you want ksh. The problem is that chsh is a setuid program that hacks the password file, so it has to be very restricted in its behaviour to avoid being a total security hole. Our local System V Rel 2 systems have a more flexible variant on chsh; I'm not sure if they're part of the vanilla distribution or if they're part of the standard Bell Labs add-on package, but it has a file of legal shells you can use. -- ## Bill Stewart, AT&T Bell Labs, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (08/15/85)
> Another reason that nags the back of my mind is a security hole, but by > the time a shell is exec'd for you in login you are already setuid()'d > and setgid()'d to you so it doesn't seem to me it opens any hole that > isn't already there...hmmm. I like this idea: $ chsh myname ' > myroot::0:1::/:' $ su myroot # Obviously chsh could check for this sort of thing, but it does demonstrate (once again) that one has to think very deviously when designing set-UID code.
conor@Glacier.ARPA (Conor Rafferty) (08/16/85)
In article <1229@umcp-cs.UUCP> chris@umcp-cs.UUCP (Chris Torek) writes: >We (well, Fred actually) modified chsh to read /lib/ok_shells for >a list of the shells "ordinary users" can set up. It's more anti- >accidental-stupidity than anything else. I've heard the "protecting people from themselves" argument a few times now, but it seems flimsy to me. After all, you can destroy everything you ever wrote with a single rm -fr *, whereas chsh <me> /bin/false just requires a trip up the corridor to your sysadmin. Do we make rm a privileged command? Of course not. It seems like we can get by without this bit of paternalism in chsh too. It's not an important point, but there is an important issue behind it: are checks to protect novices to be taken over the line where they limit the freedom of experienced users? After /lib/ok_shells, why not /lib/ok_commands /lib/allowed_paths and mandatory "noclobber"? It doesn't sound like Unix to me! Conor Rafferty conor@su-glacier.arpa 231A Applied Electronics Lab. conor@su-sierra.arpa Stanford University Ca.94305 decwrl!glacier!conor (415)497-1515
arnold@ucsfcgl.UUCP (Ken Arnold%CGL) (08/17/85)
>>From: conor@Glacier.ARPA (Conor Rafferty) >>Subject: Alternate Shells >>Summary: Why is chsh fascist? > >>A quickie: 4.2BSD chsh does not allow the user to specify alternative >>shells - only "sh" and "csh" are permitted. Why is this? It seems >>ironically inappropriate in UNIX, where the shell is ``an ordinary, >>swappable user program'' and ``user-selectable system interfaces [...] >>become essentially trivial to implement'' [Ritchie & Thompson CACM 1974]. > >One obvious reason probably had more to do with the 'nuisance' of people >setting various things to be their shell and then finding out it was a >bad choice... I helped make this decision -- it was because people who left their terminals unattended for a few minutes (to relieve themselves, say) would find themselves with a strange shell the next time they logged on. This kind of prank became such a pain (besides being virtually unfixable without finding a super-user, a species of (alleged) person not always available when you have an assigment due the next morning) that we decided to turn off chsh to non-normal shells except for root. Ken Arnold
rfb@cmu-cs-h.ARPA (Rick Busdiecker) (08/18/85)
In response to Ken Arnolds August 16th post: Why did you disable switching to other shells rather than simply demanding the users password before completing the shell switch? Rick Busdiecker rfb@cmu-cs-h
seifert@hammer.UUCP (Snoopy) (08/18/85)
In article <615@ucsfcgl.UUCP> arnold@ucsfcgl.UUCP (Ken Arnold) writes: >I helped make this decision -- it was because people who left their >terminals unattended for a few minutes (to relieve themselves, say) >would find themselves with a strange shell the next time they logged >on. A rather poor reason to limit the usefulness of chsh. Haven't you heard about "block" (also known as "lock", etc.) a program which requires you to type in your password before letting you do anything? (without having to go through all the grief of logging out and back in again) Bozo-proofing chsh does nothing about all the other interesting things that can happen to your account if you leave your terminal unlocked. Snoopy tektronix!hammer!seifert These opinions should be considered mine, not those of Tektronix. In this case they do appear to agree, since Utek's chsh isn't fascist.
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (08/18/85)
> I helped make this decision -- it was because people who left their > terminals unattended for a few minutes (to relieve themselves, say) > would find themselves with a strange shell the next time they logged > on. This kind of prank became such a pain (besides being virtually > unfixable without finding a super-user, a species of (alleged) person > not always available when you have an assigment due the next morning) > that we decided to turn off chsh to non-normal shells except for root. But that doesn't help. The prankster can always add something like exec echo goodbye as the last line of a .profile (or .login) even if chsh never existed. The solution to unattended logged-in terminals is to not have any.
herbie@watdcsu.UUCP (Herb Chong - DCS) (08/19/85)
In article <615@ucsfcgl.UUCP> arnold@ucsfcgl.UUCP (Ken Arnold) writes: >I helped make this decision -- it was because people who left their >terminals unattended for a few minutes (to relieve themselves, say) >would find themselves with a strange shell the next time they logged >on. This kind of prank became such a pain (besides being virtually >unfixable without finding a super-user, a species of (alleged) person >not always available when you have an assigment due the next morning) >that we decided to turn off chsh to non-normal shells except for root. but making changes to the list of "valid" shells inaccessible except by modification of source brings up several points: 1) binary only sites require a super user's intervention whenever a user wants to change shells (not often) to others that may be available (vsh, ksh, tcsh come to mind) 2) the biggest computer security problem is still people. i never leave my terminal unattended. either someone i trust watches it, i lock it up, or i lock the door, depending on where i am. 3) a valid list that is compiled in or read from a file provides a lot more flexibility anyway Herb Chong... I'm user-friendly -- I don't byte, I nybble.... UUCP: {decvax|utzoo|ihnp4|allegra|clyde}!watmath!water!watdcsu!herbie CSNET: herbie%watdcsu@waterloo.csnet ARPA: herbie%watdcsu%waterloo.csnet@csnet-relay.arpa NETNORTH, BITNET, EARN: herbie@watdcs, herbie@watdcsu
iwm@icdoc.UUCP (Ian Moor) (08/21/85)
In article <615@ucsfcgl.UUCP> arnold@ucsfcgl.UUCP (Ken Arnold) writes: >>>A quickie: 4.2BSD chsh does not allow the user to specify alternative >>>shells - only "sh" and "csh" are permitted. Why is this? >I helped make this decision -- it was because people who left their >terminals unattended for a few minutes (to relieve themselves, say) >would find themselves with a strange shell the next time they logged >on. Surely being able to change your password interactively can cause just the same problem and passwd has a solution, ask for your current password. Its more difficult to stop people changing your .login though. -- Ian W Moor The squire on the hippopotamus is equal Department of Computing to the sons of the other two squires. Imperial College. 180 Queensgate London SW7 Uk.
rml@hpfcla.UUCP (08/22/85)
> >A quickie: 4.2BSD chsh does not allow the user to specify alternative > >shells - only "sh" and "csh" are permitted. Why is this? It seems > >ironically inappropriate in UNIX, where the shell is ``an ordinary, > >swappable user program'' and ``user-selectable system interfaces [...] > >become essentially trivial to implement'' [Ritchie & Thompson CACM 1974]. > > I think you can see it more as a site policy rather than a restriction > imposed by UNIX. Go bug your SA if you have a good argument. I agree, that it should a matter of site policy. Some system administrators like the idea that the Bourne shell executes commands from /etc/profile every time a user logs in, so they can have some control of what the user sees or does at that time (like /etc/motd). There were thus administrators who didn't like csh as a login shell (and forced their users to use sh and exec a link to csh named -csh from .profile). For this reason HP modified csh to read commands from a file /etc/csh.login prior to ~/.login. Having chsh read a list of allowable files from a file sounds like a good solution (though I'm not sure I'd agree that the file belongs in /lib). Bob Lenk {hplabs, ihnp4}!hpfcla!rml
arnold@ucsfcgl.UUCP (Ken Arnold%CGL) (08/23/85)
In article <242@cmu-cs-h.ARPA> rfb@cmu-cs-h.ARPA (Rick Busdiecker) writes: >Why did you disable switching to other shells rather than simply demanding >the users password before completing the shell switch? (a) It was easier to implement (b) We saw little reason for anybody to use any other shell (you must remember that csh was new then, and there were no other alternative shells). The only other common shell used was a basic+ interpreter for one business class, which was given by the administrator when the class accounts were set up. I do not mean to defend this as the correct solution in today's circumstances. Somebody reported modifying their chsh to look in /lib/ok_shells instead of having a hardwired list, which makes more sense. But in a world where there were only two shells, it was the most obvious solution, and I thought I'd enlighten on a minor point of UNIX history in which I was involed. Ken Arnold
arnold@ucsfcgl.UUCP (Ken Arnold%CGL) (08/23/85)
In article <782@brl-tgr.ARPA> gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) writes: >> [explanation by me of why chsh is limited to two shells in order to avoid >> pranks being played on people in the bathroom, or wherever] > >But that doesn't help. The prankster can always add something like > exec echo goodbye >as the last line of a .profile (or .login) even if chsh never existed. >The solution to unattended logged-in terminals is to not have any. You can never convince people that if they just run off and relieve themselves or get a candy bar that they can't just leave the terminal alone (just for a second). At least until somebody has screwed them up at least once. There are a large number of ways to mess up such people, but even messing with a .profile can at least potentially be bypassed by leaning on a repeating delete key as you log in, and hope to interrupt processing of the .cshrc/.login/.profile file. With chsh pranks, you can (by definition) do nothing. Ken Arnold
hosking@convexs.UUCP (08/24/85)
> A rather poor reason to limit the usefulness of chsh. Haven't you > heard about "block" (also known as "lock", etc.) a program which requires > you to type in your password before letting you do anything? Next joke, please. Suffice it to say that "lock" isn't nearly as secure as it might lead you to believe. This probably isn't the place to go into the details of why, but I wouldn't trust the standard "lock" to protect anything I valued. Doug Hosking Convex Computer Corp. Richardson, TX {allegra, ihnp4, uiucdcs}!convex!hosking
david@wisc-rsch.arpa (David Parter) (08/27/85)
> Next joke, please. Suffice it to say that "lock" isn't nearly as > secure as it might lead you to believe. This probably isn't the > place to go into the details of why, but I wouldn't trust the > standard "lock" to protect anything I valued. > Doug Hosking possible solutions: 1) don't leave your terminal (logged in) alone. 2) fix lock, if you need a secure locking mechanism for yourself or your users. We have made some fixes to it. david -- david parter UWisc Systems Lab uucp: ...!{allegra,harvard,ihnp4,seismo, topaz}!uwvax!david arpa now: david@wisc-rsch.arpa arpa soon: david@wisc-rsch.WISCONSIN.EDU or something like that
carl@bdaemon.UUCP (carl) (08/27/85)
> >But that doesn't help. The prankster can always add something like > > exec echo goodbye > >as the last line of a .profile (or .login) even if chsh never existed. > >The solution to unattended logged-in terminals is to not have any. If we are going to be really nasty in the way we want to teach people not to leave un-attended logged-in terminals, why not add set -n to their .profile? Carl Brandauer daemon associates 1760 Sunset Blvd. Boulder, CO 80302 {allegra|amd|attunix|cbosgd|ucbvax}!nbires!bdaemon!carl
levy@ttrdc.UUCP (Daniel R. Levy) (08/28/85)
In article <275@uwvax.UUCP>, david@wisc-rsch.arpa (David Parter) writes: >> Next joke, please. Suffice it to say that "lock" isn't nearly as >> secure as it might lead you to believe. This probably isn't the >> place to go into the details of why, but I wouldn't trust the >> standard "lock" to protect anything I valued. > >> Doug Hosking > >possible solutions: > 1) don't leave your terminal (logged in) alone. > 2) fix lock, if you need a secure locking mechanism for yourself > or your users. We have made some fixes to it. > >david >-- >david parter >UWisc Systems Lab > >uucp: ...!{allegra,harvard,ihnp4,seismo, topaz}!uwvax!david >arpa now: david@wisc-rsch.arpa >arpa soon: david@wisc-rsch.WISCONSIN.EDU or something like that I didn't see the original (Hosking) so I am replying to this one. The key to the extant lock can be pried by anyone who has access to the source code, or who can do a strings on the binary. It's an open secret, and I'm sure every hacker from Maine to California knows it. If you MUST have a master key to lock change it from the default and make the source and binary readable only to root (if at all). Actually I don't even see the need for a master key at all; if you forget, just log in elsewhere and kill the process with signal 9. (And stty sane < /dev/tty_whatever.) -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer, my pets, my plants, my boss, or the | at&t computer systems division | s.a. of any computer upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!ihnp4!ttrdc!levy or: ..!ihnp4!iheds!ttbcad!levy
arnold@ucsfcgl.UUCP (Ken Arnold%CGL) (08/28/85)
In article <275@uwvax.UUCP> david@wisc-rsch.arpa (David Parter) writes: >> Next joke, please. Suffice it to say that "lock" isn't nearly as >> secure as it might lead you to believe. This probably isn't the >> place to go into the details of why, but I wouldn't trust the >> standard "lock" to protect anything I valued. >> Doug Hosking >possible solutions: > 1) don't leave your terminal (logged in) alone. > 2) fix lock, if you need a secure locking mechanism for yourself > or your users. We have made some fixes to it. All missing the point. You try and convince a bunch of beginning programmers that they should never walk away from their terminal without locking it. You'll get to about 80% of them initially, and then after about a week, people will start to get careless, and you start getting a very low compliance rate. Also, as security sometimes one will just ask a friend to watch the terminal while they go to the bathroom, and that friend is the one who plays the practical joke. In the real world, you just cannot convince *everyone* (or even a significant fraction) to be paranoid; most people just don't think that way. Hell, even *I* don't think that way all the time, thank goodness. The software should assume a somewhat hostile environment. If you don't believe me, let me point out that changing the login shell to /bin/cat and changing someone's password both lock them out of their account. Do I hear anyone arguing that passwd should stop asking for the current password before changing it to something else? No. So why shouldn't chsh give some security? There are better ways than the two-shell restriction currently in use, but some such restriction is needed. Ken Arnold
notch@srcsip.UUCP (Michael k Notch) (08/29/85)
In article <275@uwvax.UUCP> david@wisc-rsch.arpa (David Parter) writes: > >> Next joke, please. Suffice it to say that "lock" isn't nearly as >> secure as it might lead you to believe. This probably isn't the >> place to go into the details of why, but I wouldn't trust the >> standard "lock" to protect anything I valued. > >> Doug Hosking > >possible solutions: > 1) don't leave your terminal (logged in) alone. > 2) fix lock, if you need a secure locking mechanism for yourself > or your users. We have made some fixes to it. > >david >-- >david parter >UWisc Systems Lab > >uucp: ...!{allegra,harvard,ihnp4,seismo, topaz}!uwvax!david >arpa now: david@wisc-rsch.arpa >arpa soon: david@wisc-rsch.WISCONSIN.EDU or something like that To: david@wisc-rsch.arpa Subject: Re: Alternate Shells Newsgroups: net.unix In-Reply-To: <275@uwvax.UUCP> References: <49600007@convexs> <10672@Glacier.ARPA> Organization: Honeywell SRC (SIP), Mpls MN Cc: Bcc: In article <275@uwvax.UUCP> you write: > >> Next joke, please. Suffice it to say that "lock" isn't nearly as >> secure as it might lead you to believe. This probably isn't the >> place to go into the details of why, but I wouldn't trust the >> standard "lock" to protect anything I valued. > >> Doug Hosking > If you could, could you send me the entire new program that you have made to fix the locking problems. I am very interested in these problems and if there are anymore fixes you think I might like, please feel to send them. Thanks in advance. -- But... What about Naomi? USENET: ihnp4!umn-cs!srcsip!notch US-SMAIL: Michael k Notch (The small k is on purpose) MN17-2349 [1-612-378-5338] Honeywell Inc. Systems & Research Center 2600 Ridgeway Parkway NE Minneapolis, Minnesota 55440 --
peter@baylor.UUCP (Peter da Silva) (08/29/85)
> (b) We saw little reason for anybody to use any other shell (you must > remember that csh was new then, and there were no other alternative > shells). The only other common shell used was a basic+ interpreter for > one business class, which was given by the administrator when the class > accounts were set up. What about psh? I seem to remember running into a couple of people who preferred it to csh. I thought they were crazy but that doesn't mean anything. I frequently think I'm crazy. -- Peter (Made in Australia) da Silva UUCP: ...!shell!neuro1!{hyd-ptd,baylor,datafac}!peter MCI: PDASILVA; CIS: 70216,1076
peter@graffiti.UUCP (Peter da Silva) (08/30/85)
> .profile). For this reason HP modified csh to read commands from a file > /etc/csh.login prior to ~/.login. Having chsh read a list of allowable > files from a file sounds like a good solution (though I'm not sure I'd > agree that the file belongs in /lib). I've seen 2 other versions of csh. One sources /etc/cshrc, the other sources *each* .login in the path to $HOME (!). I had been under the impression that /etc/cshrc was a standard way of doing things...
roy@phri.UUCP (Roy Smith) (08/30/85)
[flame-ish debate about password security, etc.] > There are better ways than the two-shell restriction currently in use, > but some such restriction is needed. > Ken Arnold The whole idea of passwords is a kludge anyway, propagated by people trying to cover up fundamental flaws in system design. In 16 years we can all go out and buy HAL-9000's with true voice/face recognition built-in. Until then, I guess we'll just have to live with what we have now. BTW, anybody know if you can run 4.17 bsd on a HAL-9000 with only 2 Terra-bytes of nuero-RAM? Also, anybody know if they *finally* have a good Fortran math library? :-) -- Roy Smith <allegra!phri!roy> System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
henry@utzoo.UUCP (Henry Spencer) (09/06/85)
> BTW, anybody know if you can run 4.17 bsd on a HAL-9000 with only > 2 Terra-bytes of nuero-RAM?... :-) No, 4.17 requires at least 3.5 petabytes (peta == 10**15, by the way) for the kernel. There is good news, though! The new 4.17 C shell (which incorporates three different window managers, two TCP/IP implementations, a graphics package for the Sun 357, and several thousand new features) will actually fit in only a terabyte. The manual page for cat(1) has been condensed (by using 6-point type) so that it only weighs three pounds despite a few dozen new options. And the distribution tapes only fill a single moving van at 6757600000 bpi. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry