buck@drax.gsfc.nasa.gov (Loren (Buck) Buchanan) (09/21/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..."harrys@tons61.UUCP (Harry Skelton) (09/22/89)
[ refs from: ] >From: bob@omni.com (Bob Weissman) >From: mrm@Sceard.COM (M.R.Murphy) >From: msdc!peter@gatech.edu (Peter N. Wan) >From: Dave Remien <dave@uunet.uu.net> [ and poster not able to accept sugestions ] Here at the DOT we have a login.c program that can secure any terminal or lockout any user from any terminal with a few configuration files. The source was obtained from our vendor but the basic source was of USENET postings. In /etc there are files such as /etc/securetty /etc/nologin /etc/issue [*sic*] and others that allow configuration of modem ports, regular terminal ports, prohibit root logins (actually pretty nice considering) and more! Check your local archive site for the 'login' sources. If you need a good copy - e-mail me and I'll ship you the version(s) we have. BTW: ours support remote system logins....with security -- Harry Skelton - Senior Systems Administrator - U.S. Dept. of Transportation ..!attctc!tons61!harrys ..!obdient!tons61!harrys ..!tfd!tons61!harrys [ Views expressed by Harry Skelton are not those of the US Gov. or CBSI ]
randy@chinet.chi.il.us (Randy Suess) (09/26/89)
In article <113@tons61.UUCP> harrys@tons61.UUCP (Harry Skelton) writes:
]
]Here at the DOT we have a login.c program that can secure any terminal or
]lockout any user from any terminal with a few configuration files. The
]source was obtained from our vendor but the basic source was of USENET
]postings. In /etc there are files such as /etc/securetty /etc/nologin
]/etc/issue [*sic*] and others that allow configuration of modem ports,
This was originally written by a local user, Dave Ihnat
(ignatz@chinet.chi.il.us) for chinet a number of years
ago. Conditional compiles for SysV, V7, XENIX, BSD,
privledged lines, privledged users based on uid, gid, login
shell (i.e. uucico for uucp only lines), passwd ageing,
lastlog capabilities, etc. I believe he either did or is
in the process of adding /etc/shadow. Source available.
-randy
--
Randy Suess
randy@chinet.chi.il.uslarry@nstar.UUCP (Larry Snyder) (09/27/89)
Randy is Chinet importing Usenet news into a message base or BBS of any kind or do you allow uses access to the shell and vnews? -- Larry Snyder uucp:iuvax!ndcheg!ndmath!nstar!larry The Northern Star Usenet Distribution Site Notre Dame, IN USA