			       The Terminal Locker
			       
	Before beginning- let me apologize for errors due to grammar and fast
typing (I don't have time to sit around and proof-read any documentation).

	I originally got the idea for this 'shell' because of problems where
I work at Georgia Southern. We have been having one of those annoying people
that has nothing better to do with their lives than talk on IRCs; so he/she
has been using hacker utilities pulled from the net to attack our machines and
try to set them up as IRCs using BitchX. Amusingly enough, this idiot actually
acts offended that we won't allow him/her to do this. Anyway, he/she appeared
to be getting in by flooding the machines with millions of requests to try to
crash the login services- which apparently worked. I think I have heard of
this before (referred to as a "flood" attack ?) so I wasn't suprised when our
logs showed this. Unfortunately, not being an administrator, I don't know how
to stop the attack.
	After many temporary security measures, I had the idea of focusing
on stopping the "hacker" (I use this term loosely since this person is no more
a hacker than any other person who can type in a command at a prompt) after
he/she got in rather than trying to stop him/her from getting in (which, as
I stated, I don't know how to do). I figured, based on finding hacker packages
used by the person in question, that this person is probably helpless without
these utilities written by other people. My idea, simple as it is (as most of
my ideas are), was to make a crippled "shell" that does not act as a command
interface. This stops the "hacker" from logging in and FTPing one of his/her
cute little hacker utilities onto the system. It is this simple idea that I
implemented- all other things were due to other considerations that had to be
worked around (such as allowing the REAL users to be able to get their normal
terminals).

Why make it?
	Here is the advantages that I saw to putting a security gate at this
	place in the operating system:
		1. The login system for UNIX & clones consists of multiple
		   programs that are basically interchangable and easily
		   replaced. This is good for simple administration, but
		   bad for general security. If one program gets corrupted,
		   ignores a special case, or has a flaw, the whole system
		   is compromised. Also, the current login 'system' is
		   widely known and already has gobs of hacker packages to
		   attack every weak link in the system (which is easy to
		   find in Linux anyway since source code is available).
		2. I was never quite sure what happens when a login system
		   crashes. I think it may be one of those things that is
		   not quite predictable. (When you say to someone: Well,
		   it SHOULD simply log the user out...) What should
		   happen, I have found with computers, doesn't always.
		   I would appreciate if some UNIX guru would e-mail me
		   something about this- its easy to find material about
		   what programs and systems do when they are working
		   fine, but almost impossible to find information over
		   behavior under abnormal conditions.)
		3. Using TermLock, you have a simple security measure,
		   with no prior security breakers devoted to it, which
		   does not even allow outside (non-internal) utilities
		   to be used in attempts to break it. Even if a program
		   (like a dictionary cracker) that tries all combos
		   of characters were used, it would not finish for a
		   decade due to the unknown request length (at least
		   1, at most virtually unlimited). In a standard login
		   system, you can assume that the password is 8
		   characters or less; but in TermLock, no assumption
		   can be made- and usually the request will be VERY
		   long. (The one we use at GSU is over 30 characters)

	In the end, this is what I have:
	
		After logging on, the user gets a prompt like a shell prompt.
		At this prompt, user can do two things:
			logout or enter the access 'code'
		If a hacker manages to crash the shell, it will simply log
		 him/her out since it was his/her login shell (nothing gained)
		To enter access code, hacker must know how to request an
		 access code request (Access Prompt), how to separate the
		 request and the key (Access Delimeter), and the Key itself.
		 Currently, the delimeter is hard-coded (must alter source
		 to alter), but the Prompt is easily and quickly changed
		 through the rc file and the key is hard-coded in a
		 jumbled form to avoid allowing a hacker to walk up to
		 a logged in terminal and 'more'ing the TermLock binary.
		Once access code is entered, the users machine should act
		 identical to normal logins.
		As a note on the shell switching- one of the things that
		 worried me about making this utility was the proper
		 handling of signals when the real login shell started.
		 I believe that any shell started as a login shell will
		 force its own signal control. The utility and login
		 shell appears to work fine, but I do not know if the
		 child process control is as it should be. (Just
		 something to keep an eye on- I don't think it could
		 cause any system damage if the signal control isn't
		 being done)
		After a true user logs in, all of the terminals and
		 xterms started will be their regular shell, not the
		 locker.
		Linking /bin/sh (the default system shell) to termlock
		 covers the possibility that a flood attack could be
		 caused a drop into a repair shell. (This is the only
		 way that I could think that this attack could do
		 anything useful from a remote terminal) In case this
		 is the case, I wanted the /bin/sh covered for the
		 possibility of logins. Unfortunately, this link is
		 used to execute many system scripts. What I did was
		 this- if the program is invoked as a login terminal
		 (if first argument starts with a '-') then the
		 security prompt is issued, otherwise, termlock
		 assumes it is being invoked by a user or to execute
		 a script (as /bin/sh). In this case, it looks up the
		 entry under the specified script username and looks
		 up this shell entry in the login shells file. It
		 then invoked this shell with the passed arguments.
		 Example: if /bin/sh formerly linked to /bin/bash,
		          then it is changed to /bin/termlock and
		          the entry :shell:/bin/bash: is appended
		          to the login shells file. Executing
		          /bin/sh from command prompt or script
		          then acts identical to it did previously
		          (as if it was still linked to /bin/bash)
		          unless it is called as a login shell, in
		          which case, it acts like the terminal
		          locker.

