jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) (09/30/90)
In article <13970@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >Seriously, you seem to imply that there is some sort of "problem" >that needs to be solved. Just what IS the problem? This is primarily a security issue. The problem is that users will walk off and leave their terminals logged on, thus allowing someone else to walk up to the terminal and gain the security privileges of the original user. An auto-logoff is one way of fighting this problem with some chance that a problem will be prevented rather than punished. An auto-lock is a better solution, to me, but presupposes that a secure lock can be established. -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jmaynard@thesis1.hsch.utexas.edu | adequately be explained by stupidity. "It's a hardware bug!" "It's a +--------------------------------------- software bug!" "It's two...two...two bugs in one!" - _Engineer's Rap_
gwyn@smoke.BRL.MIL (Doug Gwyn) (10/01/90)
In article <4133@lib.tmc.edu> jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) writes: >In article <13970@smoke.BRL.MIL> gwyn@smoke.BRL.MIL (Doug Gwyn) writes: >>Seriously, you seem to imply that there is some sort of "problem" >>that needs to be solved. Just what IS the problem? >This is primarily a security issue. The problem is that users will walk off >and leave their terminals logged on, thus allowing someone else to walk up >to the terminal and gain the security privileges of the original user. Ah, but you don't solve that problem by timing out the connection after a certain amount of inactivity; you merely reduce the time during which some unauthorized person can exploit this situation. To solve the problem, you need to educate your users in the necessity of logging off or at least running some sort of approved "terminal lock" program when leaving their terminal unattended, and they must be convinced that they should do it AND that failure to cooperate in computer security matters will result in suitable corrective action, such as firing them or removing their access. People problems need people solutions; attempts to automate technical solutions generally don't really work.
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/02/90)
In article <4133@lib.tmc.edu> jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) writes: > This is primarily a security issue. The problem is that users will walk off > and leave their terminals logged on, thus allowing someone else to walk up > to the terminal and gain the security privileges of the original user. An > auto-logoff is one way of fighting this problem with some chance that a > problem will be prevented rather than punished. An auto-lock is a better > solution, to me, but presupposes that a secure lock can be established. Hey, folks, guess which program solves this problem too! Rather than forcibly logging the tty out, disconnect it (by sending a HUP to the pty signaller, for example). The user can log in any time later and get back to exactly where he was in the session. Naturally, this has the effect of an autolock: the user needs his password to log in so that he can get back into the session. And it's not as drastic as an autologout. pty. It slices! It dices! It autodisconnects! :-) ---Dan
jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) (10/02/90)
In article <18986:Oct120:22:5990@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >pty. It slices! It dices! It autodisconnects! :-) Yes, but does it run on System V with ptys? Sounds like a cron daemon to figure out who's idle for some amount of time, and then kill(pid,SIGHUP) the offenders, would be just the thing with everyone going through pty. Tell me, though, Dan: will it feed my cats when I'm away? :-) -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jmaynard@thesis1.hsch.utexas.edu | adequately be explained by stupidity. "It's a hardware bug!" "It's a +--------------------------------------- software bug!" "It's two...two...two bugs in one!" - _Engineer's Rap_
irick@ecn.purdue.edu (GarBear Irick) (10/02/90)
Dan Bernstein writes: > >Hey, folks, guess which program solves this problem too! > >Rather than forcibly logging the tty out, disconnect it (by sending a >HUP to the pty signaller, for example). The user can log in any time >later and get back to exactly where he was in the session. Naturally, >this has the effect of an autolock: the user needs his password to log >in so that he can get back into the session. And it's not as drastic as >an autologout. > >pty. It slices! It dices! It autodisconnects! :-) > >---Dan Is there ANYONE else out there who is sick and tired of hearing people sing the praises of pty? It may be a durn fine piece of code, but I don't think ANYTHING deserves the hype that I have been seeing... Maybe, SOMEDAY, when our machine *GETS* pty, I will see the light... :) Please, let's suggest some solutions with EXISTING tools, just ONCE, ok, Dan? Not all of us are fortunate enough to have "pty: the wonder-program", and would like to solve the problem with old tools put to new uses. One more "use pty, of course!" answer, and I think I may be forced to bite the head of a live consultant... :-) -- Gary A. Irick, Purdue University | "You can log out any time you like, INTERNET: irick@en.ecn.purdue.edu | But you can never leave!" UUCP: ...!pur-ee!irick | (apologies to The Eagles)
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/03/90)
To answer your question, pty 3.001 and its first patch are available via anonymous ftp to stealth.acf.nyu.edu (128.122.128.22) or through mail to me at brnstnd@nyu.edu. They've been waiting on the comp.sources.unix queue for a while; ask Rich Salz, rsalz@uunet.uu.net, for details. I'm always here to help with installation and applications. pty should work without trouble on any BSD 4.2 or 4.3 variant---but not on POSIX-based systems. (I'm working on a port.) In article <1990Oct2.062510.3419@ecn.purdue.edu> irick@ecn.purdue.edu (GarBear Irick) writes: > Dan Bernstein writes: > >pty. It slices! It dices! It autodisconnects! :-) > Is there ANYONE else out there who is sick and tired of hearing people sing > the praises of pty? Well, not me, since I've been doing most of the singing. :-) > It may be a durn fine piece of code, but I don't think > ANYTHING deserves the hype that I have been seeing... Maybe, SOMEDAY, when > our machine *GETS* pty, I will see the light... :) Please, let's suggest > some solutions with EXISTING tools, just ONCE, ok, Dan? It's not hype; I'm only describing working features of a program I've written. If you want to get pty for your machine, send a polite note to your sysadmin, or bring the code in and compile it yourself (though you won't get most of the security features that way). And pty certainly does exist. Is it my fault that one program solves so many problems? ---Dan
net@tub.UUCP (Oliver Laumann) (10/04/90)
In article <10547:Oct220:47:2290@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > > Is it my fault that one program solves so many problems? Yes. ``Do one thing well''. -- Oliver Laumann net@TUB.BITNET net@tub.cs.tu-berlin.de net@tub.UUCP
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/06/90)
In article <1763@tub.UUCP> net@tub.UUCP (Oliver Laumann) writes: > In article <10547:Oct220:47:2290@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > > Is it my fault that one program solves so many problems? > Yes. ``Do one thing well''. But that's what I did! I swear! I mean, it'd even chop a hundred lines out of your ``screen'' program, while improving portability, if you used pty! And out of telnetd and expect and window and lots of other programs! Doesn't this qualify as doing one thing (pseudo-tty management) well? Sort of like ``cat'', I think, except that cat has been around somewhat longer. :-) ---Dan