[comp.unix.internals] Changing tty drivers

jeff@onion.pdx.com (Jeff Beadles) (10/17/90)

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

peter@ficc.ferranti.com (Peter da Silva) (10/18/90)

There do exist terminals for which ^G is not a Bell. On some ADM terminals
it is a *transmit screen* command! Just the sort of thing to put in the
password prompt.
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter@ferranti.com

brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/18/90)

In article <KGH600D@xds13.ferranti.com> peter@ficc.ferranti.com (Peter da Silva) writes:
> There do exist terminals for which ^G is not a Bell. On some ADM terminals
> it is a *transmit screen* command! Just the sort of thing to put in the
> password prompt.

Well, then, I guess we'll have to use some character that all terminals
will accept without strange modifications. Like... e. Yeah, that's it.
e. Double all e's, except those output by root processes. Note that all
unprintable characters must be trashed, since otherwise they could be
used to mask one of the repeated characters.

I suggest that it's better to use existing utilities than to muck in
weird and wonderful ways with the kernel.

---Dan

cedman@lynx.ps.uci.edu (Carl Edman) (10/18/90)

After all the criticism that the idea of double-bell has gotten
here I think I'll have to defend it. It is quite a cute idea
and most criticism doesn't apply.

1. The problem with spoof programs which caused this solution
to be suggested is mainly a problem of publicly accessible
directly-connected terminals.

2. Such terminals are usually dumb, so that the problem of
messing up file transfer protocols really doesn't exists.
Dialup lines aren't (as much) threatened by this kind of
hack , so they of course don't get the double bell

3. What types of terminals there are is well known to those
who install double-bell protection, so that the problem
of ^G meaning anything else but bell on the particular
type of terminal used is really non-existent.

Summary: I think it is a good and simple idea, which (in contrast
to almost all other suggestions made in this group) actually
would work.

	Carl Edman

Theorectial Physicist,N.:A physicist whose   | Send mail
existence is postulated, to make the numbers |  to
balance but who is never actually observed   | cedman@golem.ps.uci.edu
in the laboratory.                           | edmanc@uciph0.ps.uci.edu

tif@doorstop.austin.ibm.com (Paul Chamberlain) (10/18/90)

brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes sarcastically:
>Well, then, I guess we'll have to use some character that all terminals
>will accept without strange modifications. Like... e. Yeah, that's it.
>e. Double all e's, except those output by root processes.

Okay, so doubling all bell characters wasn't an idea without problems,
but I have to admit it was an _interesting_ idea.

Paul Chamberlain | I do NOT represent IBM.     tif@doorstop, sc30661 at ausvm6
512/838-7008     | ...!cs.utexas.edu!ibmaus!auschs!doorstop.austin.ibm.com!tif