Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zephyr.ens.tek.com!tektronix!nosun!qiclab!onion!jeff
From: jeff@onion.pdx.com (Jeff Beadles)
Newsgroups: comp.unix.internals
Subject: Changing tty drivers (was Re: Finding Passwords)
Message-ID: <1990Oct16.173128.7280@onion.pdx.com>
Date: 16 Oct 90 17:31:28 GMT
References: <24752@adm.BRL.MIL>
Reply-To: jeff@onion.pdx.com
Organization: Little to none.
Lines: 33

In <24752@adm.BRL.MIL> emsca!usb!poc@sun.com writes:
...
 >A simpler solution is this: any non-privileged process writing a BEL
 >(Ctrl-G) to the terminal has it duplicated in the tt output queue, i.e.
 >	write (1, "\007", 1);
 >has the effect of
 >	write (1, "\007\007", 2);
 >Privileged processes on the other hand do not suffer this modification.
 >Now include a (single) BEL in e.g. the 'Password: ' prompt, y voila!
 >(Maybe you want it optional e.g. only in response to a BREAK).
 >
 >This idea was used in the secure CAP operating system built at Cambridge
 >in the 70's. Credit goes (I think) to Chris Slinn.
 >
 >Patrick O'Callaghan	"The secret is to bang the rocks together, folks"
 >Departamento de Computacion, Universidad Simon Bolivar, Caracas, Venezuela

ACK!  This is really dumb!

What if the tty is in process of sending a binary file?  That would
automatically corrupt the file.  This would blast most any protocol (ie: uucp,
{x,y,z}modem, kermit, ...) out of the water.  (Well, they would continue
resending the block getting failures from the checksums...)

Now, if you say that if the tty could be put in "raw" mode, and this be
averted, then you've just found out how the "bad guy" could get past this
annoyance.

This is NOT an intelligent thing to do...

	-Jeff
-- 
Jeff Beadles	jeff@onion.pdx.com