bzs@bu-cs.bu.edu (Barry Shein) (04/22/89)
anderer@vax1.acs.udel.edu (David G Anderer): >Problem: How do I prevent people from getting to the server via TELNET or >RLOGIN? There's no reason they should run jobs on the server, and a good >one they shouldn't. Well, you could put a message to that effect in /etc/motd on the server. If you really want to prevent this you probably need to widen your scope of what you're preventing them from doing, like using RSH or ON or using the REXEC routines themselves. If you want only root on the machine it's easy, just create an /etc/nologin file with a message in it to that effect. Note that reboots manipulate this file, may have to recreate from rc.local but that's no big deal (echo 'No User Logins' > /etc/nologin). You could set their shell path in the passwd file to a program which checks who they are and what machine it's running on and either execs their correct shell (could look at its argv[0]) or exits. If you use a group to identify who can log in it's probably 20 lines of C code (tho you probably want to be careful with testing what happens if ^C etc. is sent, probably just exits.) -- -Barry Shein, Software Tool & Die There's nothing more terrifying to hardware vendors than satisfied customers.
scs@lokkur.UUCP (Steve Simmons) (04/22/89)
anderer@vax1.acs.udel.edu (David G Anderer) writes: >My one solution was to use some file other than /etc/passwd as the YP >passwd map (such as /etc/passwd.clients). That works, except the server >then has no knowledge of these accounts, and so things like ls -l on the >server are messy because they display user numbers rather than user names. > >If there a way (short of source) to only allow SOME accounts remote access >to the server? Several, but you've already got 99% of your solution. Use an alternate file for yp password management. Write a filter that will take the yp alternate file will change line like scs:xaoiuSUDF&879:102:102:Steve Simmons:/u/scs:/bin/ksh to scs:xaoiuSUDF&879:102:102:Steve Simmons:/u/scs:/etc/sorrysh ^^^^^^^^^^^ Put this new file into /etc/passwd. Now when people rlogin to the server, they get the program /etc/sorrysh as their shell. Here's the code for /etc/sorrysh: main() { (void) printf( "Sorry, you can't log into the server.\n" ) ; } And now they can't log in. You'll probably want to make a list of 'exempt' ids who get their normal shells. The script is left as an exercise for the student... :-) -- Steve Simmons, Inland Sea Software, Ltd. scs@lokkur.dexter.mi.us 9353 Hidden Lake, Dexter, MI. 48130 313-426-8981
brent@uunet.uu.net (Brent Chapman) (04/22/89)
Your YP solution is the first part of what you need. The second is to
keep everyone in the "real" /etc/passwd file on the server, but to give
them a null password (or a "*" password) and a login shell that is simply
a shell script or program that says "sorry, authorized users only on the
server", waits a few seconds, and then exits, dumping them off. The pause
is so that the "sorry" message gets printed before the shell exits and the
modem line, port selector line, or telnet connection is dropped.
-Brent
--
Brent Chapman Capital Market Technology, Inc.
Computer Operations Manager 1995 University Ave., Suite 390
brent@capmkt.com Berkeley, CA 94704
{cogsci,lll-tis,uunet}!capmkt!brent Phone: 415/540-6400jbw%bucsf.BU.EDU@bu-cs.bu.edu (Joe Wells) (04/22/89)
anderer@vax1.acs.udel.edu (David G Anderer) writes: >There's no reason they should run jobs on the server, and a good >one they shouldn't. Do you have any statistics to back this up, or is this a impression that you get? It seems to me that running a job on the workstation takes up just as much of the server's resources as running it on the server would. Can anyone else comment knowledgeably on this subject? [[ How do you know that that was the "good" reason? To answer your question: it depends on what the program is doing. If it is CPU intensive without generating many or any page faults, then clearly it will put a far greater load on a server if run there than if run on the client. --wnl ]] -- Joe Wells INTERNET: jbw%bucsf.bu.edu@bu-it.bu.edu IP: [128.197.10.201] UUCP: ...!harvard!bu-cs!bucsf!jbw
young@ll-vlsi.arpa (George Young) (04/22/89)
We do limit access to our servers by using a separate passwd file, but
using the wildcard feature of yp to retain uid-username knowledge and
restricted rsh access for ordinary users. The passwd file looks like:
root:opqrstuvwxyz:0:1:Operator:/:/bin/csh
nobody:*:-2:-2::/:
daemon:*:1:1::/:
sys:*:2:2::/:/bin/csh
bin:*:3:3::/bin:
laser:AbCdEfGhIjKl:34:2:&:/common/home/laser:/bin/csh
+:nologin:0:0:::/etc/login-disabled
where /etc/login-disabled is the script:
#!/bin/csh -f
if { /usr/bin/tty -s } then #must be a login if it has a terminal
echo Login to server is not allowed because of detrimental effect on file serving.
else
shift #shift out the first arg "-c" inserted by rsh
setenv SHELL /bin/csh
limit cputime 480seconds
limit memoryuse 240kbytes
limit datasize 2.5megabytes
nice +2
exec /bin/csh -c "$*"
endif
This arrangement gives 'root' and 'laser' full privileges. All others
have rsh access only (with resources limited), to allow use of the
server's tape drive. This is not intended to be absolutely secure, but
keeps people from casually logging and running huge jobs on the file
server.
George Young, Rm. B-141 young@ll-vlsi.arpa
MIT Lincoln Laboratory young@vlsi.ll.mit.edu
244 Wood St.
Lexington, Massachusetts 02173 (617) 981-2756jipping@cs.hope.edu (Mike Jipping) (04/22/89)
How about the following scheme. You suggested an alternate source for the
YP passwd map (e.g., /etc/passwd.clients); use that. Now in /etc/passwd
on the server, use a different login shell than /bin/csh or /bin/sh -- try
something that does nothing or kicks folks off the machine (after perhaps
recording that they trespassed). A spiffy trick for these "alternate"
shells appeared in an STB last year -- it automagically routed the user to
a free client on the network. Now, that example was for users calling in,
but it would work for you as well.
This way, a user is still known on the server, but can't telnet/rlogin to
do anything useful. And some accounts -- the ones you give a "real" login
shell to -- can still login and use the machine.
Mike Jipping
Hope College
Department of Computer Science
jipping@cs.hope.edumikem@xn.ll.mit.edu (Michael Maciolek) (04/24/89)
(The original poster wanted a way to keep some users from rlogging into
the fileserver, with various other limitations)
I don't know if there's a more elegant solution; this one's kind of tricky
and something of a kludge, but I'm doing something similar and it works
fine for us.
I also don't know if this will meet all your requirements; I assume it's
okay if users are unable to login at the server's console, as well as
being unable to login through telnet or rlogin?
The idea is that when a user logs in, instead of starting his/her normal
login shell, you call an authorization checker. If the user is logging in
on any machine *except* the server, control is passed to the shell...but
if the user tries to login on the server, s/he must pass an authorization
test.
I've included a piece of code in which the user must be a member of a
special group (in this case, group number 15) in order to log into the
machine which has a hostname of "servername". If the user is accepted,
s/he begins executing the specified shell.
If you have some users who prefer a different login shell - sh or ksh or
tcsh, you'll need a separate version of this program for each shell you
intend to support (there are ways around this. hint: use argv[0])
You'll need to add a line to your /etc/group file which lists all users
who are privileged to login to the server. The group name is irrelevant,
as long as the group number matches the #defined constant "MAGIC".
If you have any questions, send mail to
mikem@juliet.ll.mit.edu (preferred)
mikem@xn.ll.mit.edu (only if "juliet" bounces)
Michael Maciolek (617) 981-3174
Group 43 SysAdmin MIT/Lincoln Laboratory
------------------cut here------------------------------------------------------
/*
* Copyright (c) 1989 Michael J. Maciolek
*
* Permission is granted to anyone to make or distribute verbatim copies
* of this document as received, in any medium, provided that the copyright
* notice and permission notice are preserved, and that the distributor
* grants the recipient permission for further redistribution as permitted
* by this notice.
*
*/
/*
* Disclaimer
*
* The recipient accepts full responsibility for determining the suitability
* of this software for his/her particular application, and for any damages
* arising from the use of said software. The recipient shall in no event
* hold Michael J. Maciolek or the Massachusetts Institute of Technology or
* MIT/Lincoln Laboratory liable for any damages arising from the use of
* this software.
*
*/
/*
* That ought to keep the lawyers happy! :-)
*/
#include <sys/param.h>
#include <errno.h>
#define MAGIC 15
#define SERVER "servername"
#define SHELL "/bin/csh"
main(argc,argv,envp)
int argc;
char *argv[],*envp[];
{
int rv,i,glist[NGROUPS],hostname[MAXHOSTNAMELEN];
/* what is my hostname? */
rv = gethostname(hostname,MAXHOSTNAMELEN);
if (rv < 0) {
perror("gethostname");
exit(errno);
}
/* of which groups am I a member? */
rv = getgroups(NGROUPS,glist);
if (rv < 0) {
perror("getgroups");
exit(errno);
}
/* See if one of my groups is the MAGIC group */
for (i=0; i<rv; i++)
if (glist[i] == MAGIC)
break;
/*
* If this is not the server, or if I am in the privileged group, permit
* the login to proceed. Else, reject the login attempt.
*/
if ((strcmp(SERVER,hostname)!=0) || (i<rv)) {
rv = execve(SHELL,argv,envp);
perror("execve");
} else {
printf("You are not authorized to login to this machine\n");
}
}
/*---------------------cut here--------------------------------------------*/marcel@nluug.nl (Marcel Bernards) (04/25/89)
in Sun-Spots-Digest: Volume 7, Issue 211, message 18 of 19:David G Anderer writes: >Problem: How do I prevent people from getting to the server via TELNET or >RLOGIN? There's no reason they should run jobs on the server, and a good >one they shouldn't. solution: What to do create a separate passwd.yp with all yp users on the net. change passwd to the original version without +:0:0::: for every user permitted on the server add +foo: +bar: +:*: or +:nologin: -> this line prevents other users to login but all the YP UID and GID's are locally added by YP It works fine on our 4/280 SUNOS 4.0 Marcel Bernards, UNIX & Net sysadm Netherlands Energy Research Foundation ECN P.O. Box 1, 1755 ZG Petten, PHONE: 09 312246 4342 EARN/BITNET:ESU0130@HPEENR51 IP: marcel%ecn.uucp@nluug.nl UUCP: marcel@ecn.uucp,marcel%ecn.uucp@uunet.uu.net
perl@step.UUCP (Robert Perlberg) (04/27/89)
You could have all of the uid's in /etc/passwd but with a password of
":*:" so that they can be used for lookup but not for logging in. You
could then have a separate passwd.clients file for the real passwords.
Just an idea. I haven't tried this.
Robert Perlberg
Dean Witter Reynolds Inc., New York
phri!{dasys1 | philabs | mancol}!step!perljoe@uunet.uu.net (Joe Michel-Angelo) (05/05/89)
> anderer@vax1.acs.udel.edu (David G Anderer) writes: >>There's no reason they should run jobs on the server, and a good >>one they shouldn't. > > Do you have any statistics to back this up, or is this a impression that > you get? It seems to me that running a job on the workstation takes up > just as much of the server's resources as running it on the server would. > > Can anyone else comment knowledgeably on this subject? perhaps his problem isn't one of w/s vs. server in cpu runtime, perhaps it's more a matter of w/s vs. server RESOURCES.... ie: text table, inode slots, proc slots, memory, swap, etc. about once every 2 weeks we run out of text table slots on most of our servers; always due to developers testing new daemons or something; but instead of restricting access (which in my book is a NO NO!), i either reboot every friday night or eval the situation and order more hardware ... another server never hurts, ya know. admins also have other tricks... think of a scheme that would make it less 'useful' to run something on a server... like ask your manager for approval to tighten up system security and chmod 0 /dev/kmem ... then "ps" won't work and a developer without the ps command is like a nune without her hat... anyways, point is: you have to draw a line between productive and non- productive environments and let everyone know what the line is. when they tread on it, let 'em know with a nice warning & detailed explaination. restricting machine access just creates support & maint headacks for you and a resentment towards you -and- should be the absolute last thing you do [to internal staff]. "The Network Joe Angelo, VP/Technical Support - Support Group Division Adminstrator Teknekron Software Systems, Palo Alto, CA 415-325-1025 Is the Computer" joe@tss.com - uunet!tekbspa!joe - tekbspa!joe@uunet.uu.net