Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!dftsrv!drax!buck
From: buck@drax.gsfc.nasa.gov (Loren (Buck) Buchanan)
Newsgroups: comp.unix.questions
Subject: Re: Security and logins
Message-ID: <480@dftsrv.gsfc.nasa.gov>
Date: 20 Sep 89 17:18:20 GMT
Sender: news@dftsrv.gsfc.nasa.gov
Reply-To: buck@drax.gsfc.nasa.gov (Loren (Buck) Buchanan)
Organization: Computer Sciences Corporation @ NASA Goddard Space Flight Center
Lines: 89

Hi, Netlanders

Following is some of the responses (duplicates deleted).  Thanks to
all who replied.

From: bob@omni.com (Bob Weissman)

	Well, there's the obvious:  include the line

		if (`tty` != /dev/console) logout

	in the account's .login file, and make sure that account 
	doesn't have write access to .login.

This was my first thought, but the Silicon Graphics Personal IRIS
ignored the logout!?!  

From: mrm@Sceard.COM (M.R.Murphy)

	In /etc/profile or /etc/cshrc depending on which shell you choose for 
	your passwordless account, use /bin/tty to get the name of the login 
	terminal. If it is /dev/console or whatever you like then allow login 
	to continue. You will probably want to check the login name for the 
	account, too. I'd send you an exact script, but you do want this to 
	be a learning experience, don't you?

Well, yes, but...  I also tried something similar in the .cshrc file with 
some success.  But the rest of the problem came down to we have an infinite 
loop communications process that we have been terminating with a control-C, 
and the control-C also terminates the .cshrc execution and does not see the
following logout.

From: msdc!peter@gatech.edu (Peter N. Wan)
	You can generally enforce any restriction that you want by writing
	a program that enforces those restrictions and making it the shell for
	that account.  After the program checks any restrictions that it needs
	to, it can even start up a standard shell (/bin/sh or /bin/csh).  The
	shell field is the seventh field in the password file line.

From: guy@auspex.com (Guy Harris)

	You could give that user a special shell that checks whether the current
	tty is the console (see "ttyname" in your manual set), and complains and
	exits if it isn't.  Said special shell could:

	1) give them a restricted set of commands, if the intent is to
	   make it a really restricted shell;

	2) set the environment variable SHELL to their "real" shell and
	   then "exec" that shell, otherwise.

From: Dave Remien <dave@uunet.uu.net>

	How about this:

	A program named con_only:

	#include <string.h>
	main(){
		char *ttyname();
		if(!strcmp(ttyname(0), "/dev/console"))system("/bin/sh");
		exit(0);
	}

	where the login in /etc/passwd is:

	anon::21:5:placeholder for future:/whereever:/bin/con_only


	You could get fancy and use exec?(2), I suppose, but this should 
	work and be pretty UNIX non-specific.

Oh boy, yet another program to design, implement, document, and get Acceptance
Testing to approve (life in the big coding factory :-).

And the winner is none of the above (well at least not yet).  The simplest
solution was to put a password on the account for the development machine
(the one on the net), and the target machine does not have the password 
(currently its net does not leave the room).  

The next release of our software may use our communication process as 
the shell, but this may make debugging the system a bit more difficult.
We are considering other modifications to our design, particularly adding
an exit to our communications program.

Lifes a buffer, and then you get flushed.
Loren "Buck" Buchanan | internet: buck@drax.gsfc.nasa.gov | standard disclaimer
CSC, 1100 West St.    | uucp: ...!ames!dftsrv!drax!buck   | "By the horns of a
Laurel, MD 20707      | phonenet: (301) 497-2531 or 9898  | sky demon..."