Screen and secure sessions

[rcain@netcom.com (Robert Cain)]

What follows is part of a dialog I am having with netcom support right
now about the use of the Screen hyper-shell.  I've been using it
between home and work and it is awesome if you have never seen it.  The
man pages for it in ascii are ~rcain/pub/screen.man if you are on
netcom and want to check out what it can do.  There is someplace here I
could put it for anon ftp if somebody could tell me the name of that
drirectory from a netcom shell.  The dialog starts as a discussion of
the problem I have with the two or three minute inactivity timeout on
the San Jose modems and is mostly about the low impact I see it having
on resource usage.

If you know all about Screen or aren't really interested in a bunch of
justification, go forward about 100 lines to get to the part that
discusses crypto.


Peace,

Bob


> Netcom Support sez:
> > 
> > Robert Cain writes:
> > > 
> > >

[some stuff deleted]

> > > 
> > > First the short duration of your modem timeout pushes the envelope of
> > > the ridiculous.  I'm not sure what it is but when a brief conversation
> > > or call of nature causes it to disappear *IT IS TOO DAMNED SHORT*.
> > 
> > I'm sorry you have a problem with our policy, but we have no
> > intent to change it in the future. We'll take your suggestions
> > under consideration, but as I said we have no plans to modify
> > it at this time.
> 
> You certainly sound intransigent.  What would the implications of
> doubling it be for example?  You could at least try it for a while 
> and see if it has the effect of increasing the load on modem banks
> signifigantly.  What is the currently programmed inactivity interval
> anyway?  I lost it again in the middle of this damned note because
> I got a phone call.  Damn I hate it when that happens.  At lest
> this time there was a "vi -r" message in my mailbox after logging
> on.
> 
> > > 
> > > I have a solution to this that I am using on our sun network at
> > > work.  It is a package called "screen" that has wonderful features
> > > like multiple windows (all stacked one atop the other) that are
> > > easy to create and switch between if you want several contexts
> > > available at once.  The most exciting feature is that if I wish
> > > to or if my line goes down, I can reconnect to it at the next
> > > login and pick up as if nothing had happened.  This would be a
> > > wonderful feature at netcom too.  I know that your no nohup
> > > hacks prevent us from having processes that persist when we log
> > > off (OR ARE FORCED OFF) but if you changed that specifically
> > > for the screen processes and it's descendants to instead reduce
> > > them to the lowest possible priority until a reconnect then all
> > > this hassle would go away and netcom could offer a very neat
> > > feature.  IBM mainframes have had disconnect/reconnect forever and
> > > I've never understood the lack of it on Unix.  Here it is!  It
> > > is a very friendly and powerful capability.  Users would love it
> > > and the cost to netcom would be entries in process tables and
> > > swap space for the processes.  You seem to have more than enough
> > > of those kinds of resources now.  Please consider it.
> > 
> > The use of "Screen" is not supported on Netcom because of its drain on
> > system resources.  It violates our policy against running detached
> > backround processes. This is also a policy we have no plans to modify
> > at this time.
> 
> Hmmm, I'm not sure you read me.  What I am suggesting would not
> violate the intent of your policy WRT detached background processes.
> Let me try and persuade you.
> 
> If whatever you use to kill processes upon detachment, logout or forced
> by timeout, could instead merely lower their priority to the minimum
> then, as I said, they would not load the system's cycle capacity,
> merely occupy some process specific tables and some swap space.  I am
> pretty sure that in one of the netcom newsgroups (to which I am posting
> a copy of this) we hassled this out and it was determined what the cost
> in real memory was for a process's tables that was totally swapped
> out.  It was truly insignifigant in proportion to the size of real
> memory that is on the systems.  There is little drain on system
> resources if you do this unless the number of processes becomes
> absurdly high.
> 
> Yes, there is a cost for swap space.  Is it possible to set up your
> unix to use more than one swap area?  If so then it could be arranged
> that a user's pages were swapped into storage he is paying for
> (possibly after he/she had exceeded some limit in the system swap
> area)  and then this would become a revenue generator for netcom rather
> than a drain on resources.  If that is not a thing you know how to do
> then you could simply establish a daemon that checks the number of
> processes (or the total size) and warns the user when he is in
> violation of the limit.  That limit should be based on a determination
> of the real cost in process tables and swap space rather than just set
> arbitrarily.  I don't see how my request does much more than offer
> serial line users <!!the same advantage that lucky telnet or rlogin users
> enjoy!!>.  They can and do stay logged in indefinitely and in effect have
> various processes running all the time without concern about an
> inactivity timeout.
> 
> Arguing against having a bunch of virtual windows makes no sense
> because you can effect that if you know emacs reasonably well anyway.
> Screen is just an easier way that doesn't require one to learn emacs.
> As a hypershell, Screen has *many* powerful features for power users.
> For fairly naive users only a fairly few keystrokes need be
> remembered to use it's most useful features.  In combination with
> the menu program you offer it would be very powerful across a slow
> line.
> 
> One of Screen's features is a rather elaborate filtering mechanism whereby
> all incoming keystrokes and outgoing screen data can be filtered by
> user programs.  I would like to use this to add encryption for my phone
> line.  It would be straightforward to encrypt my outgoing and incoming
> data here at my PC that is acting as a terminal since I think my terminal
> emulator has similar filter hooks so the same programs that I used on
> the netcom end or my work end would function on this end as well if I
> explicitly wrote them to be that way.  Given that, I would make Screen
> effectively my login shell, have it negotiate (via the filters) a
> secure link with my terminal emulator here at home and then go through
> another password process before invoking my startup shell.  Viola I no
> longer have to worry about someone grabbing my real password nor can I
> be snooped or spoofed between my system and a system at netcom.  This
> has *HUGE* advantages to users and I will use a cypher (IDEA) in a mode
> that is *very* fast so that the system load that would be introduced
> by the crypdec filters would not be all that great.  I have all the
> necessasary C libraries of long integer math routines and hard crypto
> functions as well as the theoretical knowledge of crypto needed to code
> what's left to write such a filter.
> 
> Hell, Screen's capability would *greatly* enhance Netcom's account
> attractiveness and good crypto could be used as a big selling point in
> attracting commercial accounts where you make substantial profit per
> account.  In fact when I get this to work I wouldn't be surprised if
> users demand it.  :-)
> 
> I have the man pages for Screen in my ~rcain/pub directory if anybody 
> at netcom wants to check out Screen's capabilities.  I could also
> make them temorarily available for incoming anon ftp if requested.
> 

Now, while all this is true in theory, in all honesty I am too deeply
involved in other things (like a day job) to actually do the
implementation I speak of but I *do* have all the tools if anybody else
wants to take a shot at writing the filters.  Since screen runs across
rlogin just fine, if this were done I could rlogin to any other machine
on the net and have a secure session across the net.  I think it could
also be made to be secure across "talk" or "irc" sessions and even
email between machines.  It could also be used as the front end to any
text based telnet port too.  So if you want to be able to dial in
securely at least and communicate with a system that is secure, and
across systems that are secure badly enough to put the time into it (or
pay me enough to quit my day job :-), here is a chance to maybe make
some history.

I think this is the right way to get a start on global network
security.  Screen offers such a rich environment for single windowed
connections already that it is a natural starting point given that it's
author has thought ahead to the kinds of filters we need.  It also
could care less what shell you run and it is transparent to the
applications running below it (from the experience I have had to date)
It is a work of art to begin with IMHO and with this crypdec capability
there would hardly be a reason not to use it since if you don't know it
and don't want to learn, you won't know Screen is there until you
invoke it's commands with the ctrl-A key (which can be changed to
anything else as an escape if you use applications that are fond of
ctrl-A.)



Peace and hoping,

Bob

-- 
Bob Cain    rcain@netcom.com   408-354-8021


           "I used to be different.  But now I'm the same."


--------------PGP 1.0 or 2.0 public key available on request.------------------
--