klein@mechp10.UUCP (Greg Klein) (03/17/89)
I need the source code for getty(1) and login(1) or something similar if a public domain version don't exist. I want to modify them to spawn ct(1) instead of a shell to dial back the user. Please email or post (to comp.sources.d ?). Thanks. ========================================================================= Greg Klein | Microcomputer Electronics Corp. voice: (206)821-2800 x702 | 12421 Willows Rd, NE uucp: ...!hplabs!hpubvwa!mechp!klein | Kirkland WA, USA 98034 =========================================================================
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (03/22/89)
In article <180001@mechp10.UUCP> klein@mechp10.UUCP (Greg Klein) writes: >I need the source code for getty(1) and login(1) or something similar if >a public domain version don't exist. I want to modify them to spawn ct(1) >instead of a shell to dial back the user. Please email or post (to >comp.sources.d ?). Thanks. A getty clone was recently posted in alt.sources. It appears to be a beta release so I expect to see a full-use version in some other newsgroup near you soon ... A login clone was posted in January or so. It lives on this machine and is currently at patchlevel 6. Patch 7 is due out three days ago and fixes all known bugs [ Hey, my vendor used to tell me this all the time. :-) ]. You may fetch 'shadow2' from the archives, or failing that, snatch it from here via anonymous UUCP. The information for that is rpp386 Any ACU 2400 12142506272 in:--in:--in: uucp The files are: % ls -l /usr/archive/login total 94 -r--r--r-- 1 uucp uucp 19764 Mar 9 15:39 login.sh.1.Z -r--r--r-- 1 uucp uucp 15849 Mar 9 15:39 login.sh.2.Z -r--r--r-- 1 uucp uucp 8614 Mar 9 15:39 login.sh.3.Z A complete index to the archive is in ~/archive. You may want to fetch that while you are in the neighborhood. -- John F. Haugh II +-Quote of the Week:------------------- VoiceNet: (214) 250-3311 Data: -6272 | "Do not drink and bake" InterNet: jfh@rpp386.Dallas.TX.US | -- Arnold Swartzenegger UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
bill@twwells.uucp (T. William Wells) (03/29/89)
In article <13853@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: : In article <180001@mechp10.UUCP> klein@mechp10.UUCP (Greg Klein) writes: : >I need the source code for getty(1) and login(1) or something similar if : >a public domain version don't exist. I want to modify them to spawn ct(1) : >instead of a shell to dial back the user. Please email or post (to : >comp.sources.d ?). Thanks. For this, if you want it done right, modify login(1). What happens is this: getty reads the first line typed by the user. It passes that off to login, which prompts for the password. If, however, the username/password is incorrect, login does *not* go back to getty, it just prompts for the user name itself. So you'd better do your modifications to login. : A getty clone was recently posted in alt.sources. It appears to be a : beta release so I expect to see a full-use version in some other : newsgroup near you soon ... It's beta mainly because I haven't had a chance to test it out on anything other than my system, because there might still be lurking bugs, because I haven't implemented anything that will let one eliminate uugetty, and because I *hate* patch1, patch2, patch999, etc., and don't intent to contribute that kind of software. On the other hand, I've had not a whit of trouble with it, and I've heard from two people who use it on non-Microport systems without problem. (Sorry about the late response, my upstream site has been in yo-yo mode for the last 10 or so days. RIght now, I'm about 5 or 6 days behind the net. Sigh.) --- Bill { uunet | novavax } !twwells!bill (BTW, I'm may be looking for a new job sometime in the next few months. If you know of a good one where I can be based in South Florida do send me e-mail.)
klein@mechp10.UUCP (Greg Klein) (03/29/89)
/ mechp10:comp.sources.d / stefan@yendor.phx.mcd.mot.com (Stefan Loesch) / 12:01 pm Mar 21, 1989 / >> >>I need the source code for getty(1) and login(1) or something similar if >>a public domain version don't exist. I want to modify them to spawn ct(1) >>instead of a shell to dial back the user. Please email or post (to > >You won't need the source for that. The Programm that is spawned is the >last field in each line of /etc/passwd (if empty default /bin/sh). >So just edit /etc/passwd for the aproppriate logins and change the last >field to PATH/ct Yes, this will work to spawn ct, but it is not secure. A remote user would be able to login with a login/passwd that has a shell associated with it, instead of one that has ct associated with it (the shell entries in /etc/passwd must be retained for local logins). ----------
dig@peritek.UUCP (Dave Gotwisner) (03/30/89)
In article <797@twwells.uucp>, bill@twwells.uucp (T. William Wells) writes: > In article <13853@rpp386.Dallas.TX.US> jfh@rpp386.Dallas.TX.US (John F. Haugh II) writes: > : In article <180001@mechp10.UUCP> klein@mechp10.UUCP (Greg Klein) writes: > : >I need the source code for getty(1) and login(1) or something similar if > : >a public domain version don't exist. I want to modify them to spawn ct(1) > : >instead of a shell to dial back the user. Please email or post (to > : >comp.sources.d ?). Thanks. > > For this, if you want it done right, modify login(1). What happens > is this: getty reads the first line typed by the user. No No. This requires Kernel source and is definitely non portable. > It passes that > off to login, which prompts for the password. If, however, the > username/password is incorrect, login does *not* go back to getty, it > just prompts for the user name itself. So you'd better do your > modifications to login. > > : A getty clone was recently posted in alt.sources. It appears to be a > : beta release so I expect to see a full-use version in some other > : newsgroup near you soon ... We had something like this at my old job. It was done without modifying any UNIX software. They had a program which was inserted between init and getty on the dialup line. Both system 5 and BSD provide the sysadmin to specify something to be called by init on a line. What it did was to maintain a list of authorized dialin users and phone numbers (all encrypted, of course). You phoned in, typed a "login name", it looked in the file, hung up the phone, and called back the number associated with the "login name". It then exec'ed getty. The program originally ran on an ancient Version 6 system (PDP 11/70), and was converted to run on Pyramid's system without too much difficulty. If there is interest in this, let me know (E-mail only), I will try to obtain a copy of it from my old company (no guarantees). -- ------------------------------------------------------------------------------ Dave Gotwisner UUCP: ...!unisoft!peritek!dig Peritek Corporation ...!vsi1!peritek!dig 5550 Redwood Road Oakland, CA 94619 Phone: 1-415-531-6500
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (04/01/89)
In article <597@peritek.UUCP> dig@peritek.UUCP (Dave Gotwisner) writes: >In article <797@twwells.uucp>, bill@twwells.uucp (T. William Wells) writes: >> For this, if you want it done right, modify login(1). What happens >> is this: getty reads the first line typed by the user. > >No No. This requires Kernel source and is definitely non portable. Huh? I don't see why. There are now freely redistributable versions of init, getty and login. Certainly modifying one of those will produce the desired result ... -- John F. Haugh II +-Quote of the Week:------------------- VoiceNet: (214) 250-3311 Data: -6272 | "Do not drink and bake" InterNet: jfh@rpp386.Dallas.TX.US | -- Arnold Swartzenegger UucpNet : <backbone>!killer!rpp386!jfh +--------------------------------------
shs@uts.amdahl.com (Steve Schoettler) (04/05/89)
In article <597@peritek.UUCP> dig@peritek.UUCP (Dave Gotwisner) writes: >In article <797@twwells.uucp>, bill@twwells.uucp (T. William Wells) writes: >> : In article <180001@mechp10.UUCP> klein@mechp10.UUCP (Greg Klein) writes: >> : >I need the source code for getty(1) and login(1) or something similar if >> : >a public domain version don't exist. I want to modify them to spawn ct(1) >> : >instead of a shell to dial back the user. Please email or post (to >> : >comp.sources.d ?). Thanks. >> > We had something like this at my old job. It was done without modifying >any UNIX software. They had a program which was inserted between >init and getty on the dialup line. Both system 5 and BSD provide the >sysadmin to specify something to be called by init on a line. What it did >was to maintain a list of authorized dialin users and phone numbers >(all encrypted, of course). You phoned in, typed a "login name", it looked >in the file, hung up the phone, and called back the number associated with >the "login name". It then exec'ed getty. The program originally ran on an >ancient Version 6 system (PDP 11/70), and was converted to run on Pyramid's >system without too much difficulty. I wrote something like this by modifying the standard unix tip program. This allowed taking advantage of a standard text file format for storing phone numbers, baud rates, etc. This also allows operation under a variety of modems (hayes and ventel). The program was invoked with "ntip myname", where there was an entry for myname in /etc/remote. All you have to do is find the place where tip makes the connection, and fork a shell, setting stdin and stdout to the serial port. I think the command I actually used inside my exec was "rlogin localhost", because I had trouble creating a getty on the dial out line. You can set stdin and stdout of the shell with the dup() command. Good luck! Steve -- Steve Schoettler shs@uts.amdahl.com {sun,decwrl,pyramid,ames,uunet}!amdahl!shs Amdahl Corp., M/S 213, 1250 E. Arques Ave, Sunnyvale, CA 94088
edw@wells.UUCP (Ed Wells) (04/07/89)
I have something on the 3B at the local high school that does this.
/bin/login is now /bin/login2. A new 'C' program called /bin/login is now
in place to detect the username and determine if the ulimit is to be upped.
It then 'exec's to /bin/login. Of course, this program can be modified
to do anything.
--
=========================================================================
Edward E. Wells Jr., President Voice: (215)-943-6061
Wells Computer Systems Corp., Box 343, Levittown, Pa. 19058
{dsinc,francis,hotps,lgnp1,mdi386,pebco}!wells!edwbnick@aucis.UUCP (Bill Nickless) (04/07/89)
In article <28@wells.UUCP>, edw@wells.UUCP (Ed Wells) writes: > > I have something on the 3B at the local high school that does this. > /bin/login is now /bin/login2. A new 'C' program called /bin/login is now > in place to detect the username and determine if the ulimit is to be upped. > It then 'exec's to /bin/login. Of course, this program can be modified > to do anything. I forsee a possible problem with this idea: Suppose we sit at a hypothetical terminal on the left of the page, with an internal glance at what happens on the right side: Terminal Session Internal Workings ---------------- ----------------- <Connection established> 1. INIT execs /bin/getty, which prints "login:" to the terminal. login: bnick 2. The user (me) enters my login name /bin/getty execs /bin/login, with the following parameters: argv[0]="login" argv[1]="bnick" So, /bin/login prints out "Password:" Password: passs_word 3. Which I (in)advertantly mistype. So, /bin/login does the check, and prints out "Login incorrect\nlogin: " Login incorrect login: bnick 4. So I retype the login name, and login Password: pass_word does it's thing, and I type the pass- word correctly, and the thing logs me in, and everybody's happy. Now consider what happens in Ed Well's system. /bin/getty exec's his new /bin/login, which has the logname as one of the arguments. His program sets the ulimit appropriately FOR THAT LOGIN. Then, the original /bin/login (now renamed to /bin/login2) gets the same login and continues. The problem is this: What's to stop someone from typing something like "root" or "news" or "sysadm" or "edw" to /bin/getty, getting the ulimit set properly, then simply failing to log in with /bin/login2, then logging in as myself? /bin/login2 will ask for a new logname when the first password check fails. A better place to set the ulimit would be /etc/profile, which IS run before every shell session. For callbacks this would be just fine, but not for setting some priveleged attribute of the terminal session. -- Bill Nickless Andrews University Computer Science Department ...!sharkey!aucis!bnick or bnick@aucis.UUCP Unix Support Group "Help! I'm locked up in this .signature factory!"
jfh@rpp386.Dallas.TX.US (John F. Haugh II) (04/08/89)
In article <28@wells.UUCP> edw@wells.UUCP (Ed Wells) writes: > I have something on the 3B at the local high school that does this. >/bin/login is now /bin/login2. A new 'C' program called /bin/login is now >in place to detect the username and determine if the ulimit is to be upped. >It then 'exec's to /bin/login. Of course, this program can be modified >to do anything. Sigh. /bin/login can be called with no arguments or with the name of a user whose account should be upped, but which the person at the keyboard doesn't have the password for. Imagine. User Shmoe gets a 15 oglebyte ulimit, user Joe get the normal, dull 1 oglebyte ulimit. Joe wants to create a 10 oglebyte file, so, he logs out and types 'shmoe' at the getty prompt. getty calls login, which recongnizes 'shmoe' as getting the hugeoid ulimit. Joe types some bogosity at the Password: prompt, and is reprompted for his READ name, which he types in and so on. Poof, so much for only Shmoe getting the hugoid ulimit ... What went wrong? The login I wrote sets your ulimit from the passwd file after the password is validated. This is just about the only spoof proof method around. -- John F. Haugh II +-Quote of the Week:------------------- VoiceNet: (214) 250-3311 Data: -6272 | "Porsche does not recommend InterNet: jfh@rpp386.Dallas.TX.US | exceeding any speed limits" UucpNet : <backbone>!killer!rpp386!jfh +-- -- Porsche Ad ------------
guy@auspex.auspex.com (Guy Harris) (04/09/89)
>> ...A new 'C' program called /bin/login is now in place to detect the >> username and determine if the ulimit is to be upped.... >I forsee a possible problem with this idea:... ... >A better place to set the ulimit would be /etc/profile, I forsee a *definite* problem with this solution, which is that "/etc/profile" is run under the UID of the user who is logging in, and only the super-user can up the ulimit. (As somebody once said, roughly, "'ulimit' is documented in the System V manuals under 'brain damage'.")
bill@bilver.UUCP (bill vermillion) (04/10/89)
In article <399@aucis.UUCP] bnick@aucis.UUCP (Bill Nickless) writes: ]In article <28@wells.UUCP>, edw@wells.UUCP (Ed Wells) writes: ]> ]> I have something on the 3B at the local high school that does this. ]> /bin/login is now /bin/login2. A new 'C' program called /bin/login is now ]> in place to detect the username and determine if the ulimit is to be upped. ]> It then 'exec's to /bin/login. Of course, this program can be modified ]> to do anything. ] ]The problem is this: What's to stop someone from typing something like ]"root" or "news" or "sysadm" or "edw" to /bin/getty, getting the ulimit ]set properly, then simply failing to log in with /bin/login2, then ]logging in as myself? /bin/login2 will ask for a new logname when the first ]password check fails. ] ]A better place to set the ulimit would be /etc/profile, which IS run before ]every shell session. For callbacks this would be just fine, but not for ]setting some priveleged attribute of the terminal session. On older software on the 3B2s the ulimit was set at 2048 and was non-configureable. The only way to get it higher was to use the login/login2 approach. Since root is the only one who can set it higher it limited uses to files of 1 meg (I found that out the hard way when trying to move some 25 meg files in a few years back). The newer system permit ulimit to be defined at a higher limit. And putting the ulimit in the profile makes sense (to me at least) on a system like that. I suspect problems with the earlier systems, and the login/login2 approach survive because of the earlier problems. -- Bill Vermillion - UUCP: {uiucuxc,hoptoad,petsd}!peora!rtmvax!bilver!bill : bill@bilver.UUCP
dig@peritek.UUCP (Dave Gotwisner) (04/12/89)
In article <14U6Pf88Sj1010WE=r6@amdahl.uts.amdahl.com>, shs@uts.amdahl.com (Steve Schoettler) writes: # In article <597@peritek.UUCP> dig@peritek.UUCP (Dave Gotwisner) writes: # >In article <797@twwells.uucp>, bill@twwells.uucp (T. William Wells) writes: # >> : In article <180001@mechp10.UUCP> klein@mechp10.UUCP (Greg Klein) writes: # >> : >I need the source code for getty(1) and login(1) or something similar if # >> : >a public domain version don't exist. I want to modify them to spawn ct(1) # >> : >instead of a shell to dial back the user. Please email or post (to # >> : >comp.sources.d ?). Thanks. # >> # > [stuff deleted] # # I wrote something like this by modifying the standard unix tip program. # This allowed taking advantage of a standard text file format for storing phone # numbers, baud rates, etc. This also allows operation under a variety of # modems (hayes and ventel). # The program was invoked with "ntip myname", where there was an entry for # myname in /etc/remote. # # All you have to do is find the place where tip makes the connection, # and fork a shell, setting stdin and stdout to the serial port. I # think the command I actually used inside my exec was "rlogin localhost", # because I had trouble creating a getty on the dial out line. You can # set stdin and stdout of the shell with the dup() command. This works fine, if you are calling from a computer. If I have a terminal at home (not a PC or workstation), I cannot run tip, I need some secure program running on the UNIX box that I am calling to prevent illegal logins. -- ------------------------------------------------------------------------------ Dave Gotwisner UUCP: ...!unisoft!peritek!dig Peritek Corporation ...!vsi1!peritek!dig 5550 Redwood Road Oakland, CA 94619 Phone: 1-415-531-6500
shs@uts.amdahl.com (Steve Schoettler) (04/13/89)
In article <623@peritek.UUCP> dig@peritek.UUCP (Dave Gotwisner) writes: >In article <14U6Pf88Sj1010WE=r6@amdahl.uts.amdahl.com>, shs@uts.amdahl.com (Steve Schoettler) writes: ># ># I wrote something like this by modifying the standard unix tip program. ># This allowed taking advantage of a standard text file format for storing phone ># numbers, baud rates, etc. This also allows operation under a variety of ># modems (hayes and ventel). ># The program was invoked with "ntip myname", where there was an entry for ># myname in /etc/remote. ># ># All you have to do is find the place where tip makes the connection, ># and fork a shell, setting stdin and stdout to the serial port. I ># think the command I actually used inside my exec was "rlogin localhost", ># because I had trouble creating a getty on the dial out line. You can ># set stdin and stdout of the shell with the dup() command. > >This works fine, if you are calling from a computer. If I have a terminal >at home (not a PC or workstation), I cannot run tip, I need some secure >program running on the UNIX box that I am calling to prevent illegal logins. >-- >------------------------------------------------------------------------------ >Dave Gotwisner UUCP: ...!unisoft!peritek!dig >Peritek Corporation ...!vsi1!peritek!dig >5550 Redwood Road >Oakland, CA 94619 Phone: 1-415-531-6500 Sorry, I guess I didn't explain it well enough. The goal is to save the user's personal phone bills. Here's what happens: user calls the computer. (can be from a terminal + modem or home computer + modem) user logs into the computer and runs ntip. then user logs off, hangs up, sets the modem on auto-answer, and the computer calls him up and forks a shell out the computer's serial port, which the user sees on his terminal, just as getty/login did when the user called the computer. Steve -- Steve Schoettler shs@uts.amdahl.com {sun,decwrl,pyramid,ames,uunet}!amdahl!shs Amdahl Corp., M/S 213, 1250 E. Arques Ave, Sunnyvale, CA 94088
dig@peritek.UUCP (Dave Gotwisner) (04/14/89)
In article <18yLb6a0ib1010aFV6Y@amdahl.uts.amdahl.com>, shs@uts.amdahl.com (Steve Schoettler) writes: # In article <623@peritek.UUCP> dig@peritek.UUCP (Dave Gotwisner) writes: # >In article <14U6Pf88Sj1010WE=r6@amdahl.uts.amdahl.com>, shs@uts.amdahl.com (Steve Schoettler) writes: # <stuff deleted -- refer to parent article> # # Sorry, I guess I didn't explain it well enough. The goal is to save the # user's personal phone bills. Here's what happens: # user calls the computer. (can be from a terminal + modem or # home computer + modem) # user logs into the computer and runs ntip. # then user logs off, hangs up, sets the modem on auto-answer, # and the computer calls him up and forks a shell out the computer's # serial port, which the user sees on his terminal, just as # getty/login did when the user called the computer. There is still a security hole here. The idea of the original post was to have a secure program running on the line (I think, at least that's what callme offers). If you can log into the system, so can anyone else who wants to run a password cracker. Even if you automate it somehow (replace login with a special program which looks at the line, and forces login to call ntip), tip (and probably ntip) has a shell escape! If the caller catches it fast enough, he could probably beat the callup. If you aren't worried about other users (possibly) getting onto your system, your approach would be fine. If you are worried (concerned), it probably isn't acceptable. -- ------------------------------------------------------------------------------ Dave Gotwisner UUCP: ...!unisoft!peritek!dig Peritek Corporation ...!vsi1!peritek!dig 5550 Redwood Road Oakland, CA 94619 Phone: 1-415-531-6500
shs@uts.amdahl.com (Steve Schoettler) (04/15/89)
In article <624@peritek.UUCP> dig@peritek.UUCP (Dave Gotwisner) writes: ># user calls the computer. (can be from a terminal + modem or ># home computer + modem) ># user logs into the computer and runs ntip. ># then user logs off, hangs up, sets the modem on auto-answer, ># and the computer calls him up and forks a shell out the computer's ># serial port, which the user sees on his terminal, just as ># getty/login did when the user called the computer. > >There is still a security hole here. The idea of the original post was >to have a secure program running on the line (I think, at least that's what >callme offers). If you can log into the system, so can anyone else who >wants to run a password cracker. Ok one more try. You call up and log in through the normal getty/login. You can't get into the system without a password and login id. Then, you run a separate program "ntip" which calls you back, forking an rlogin. When the machine dials you up, the first thing that you would see on your terminal is a Password: prompt, or the login messages (if the .rhosts were set up appropriately). In our case, the dial out line was separate from the dial in line, but this is not a requirement. I don't see how this is any less secure than the standard unix login. One security hole might be /etc/remote, which, if writable, could be changed so that a user who thinks he is calling himself, would actually send a shell out to whoever's number was in that file. So, only allow modification of /etc/remote by root. Steve -- Steve Schoettler shs@uts.amdahl.com {sun,decwrl,pyramid,ames,uunet}!amdahl!shs Amdahl Corp., M/S 213, 1250 E. Arques Ave, Sunnyvale, CA 94088