cyrus@hi.unm.edu (Tait Cyrus) (02/28/88)
I am looking for PD version of code that accomplishes the same thing
as rsh but conforms to the RFC's (machine name case independent).
We have users who like to pipe BIG jobs from one machine to another
machine via rsh's.
The reason I am interested in something other than rsh is because
here at UNM we are strongly considering disallowing the r* programs
(rsh/rcp/rlogin) because they do NOT conform to the RFC's as well
as being BIG security problems (.rhosts).
I have heard of other Universities defining their own protocols to
accomplish distributed processing without the big security holes.
I would appreciate ANY information any of you might have concerning
such protocols/utilities and there possible availability.
Thanks in advance,
--
@__________@ W. Tait Cyrus (505) 277-0806
/| /| University of New Mexico
/ | / | Dept of Electircal & Computer Engineering
@__|_______@ | Parallel Processing Research Group (PPRG)
| | | | UNM/LANL Hypercube Project
| | hc | | Albuquerque, New Mexico 87131
| @.......|..@
| / | / e-mail:
@/_________@/ cyrus@hc.dspo.govwesommer@athena.mit.edu (William Sommerfeld) (02/29/88)
In article <23511@hi.unm.edu> cyrus@hi.unm.edu (Tait Cyrus) writes: >I have heard of other Universities defining their own protocols to >accomplish distributed processing without the big security holes. >I would appreciate ANY information any of you might have concerning >such protocols/utilities and their possible availability. We should have something for you in about a month.. the Kerberos[1] authentication system developed here at Athena should be released in "about a month". It's written in C, and is known to work on the VAX and RT/PC (both running 4.3BSD UNIX), the Sun (release 3[?]), and partially (subject to memory restrictions and the lack of an operating system) on the IBM PC. We use DES as the encryption algorithm; we will [probably] ship a reasonably fast software DES to US sites, while international sites may have to find their own DES implementation[2]. Note that kerberos is not a panacea (is anything?); you still have to be careful about how you choose your password and where you type it; kerberos allows you to avoid sending your password over the network in the clear, but it can't prevent you from doing that if you so choose. If you make your files globally writable, Kerberos can't save you. We have kerberos-authenticated versions of rlogin, rsh, rcp, and NFS; we haven't done kerberos authenticated telnet or ftp [yet?], mostly because we don't use either protocol very much internally. Bill Sommerfeld MIT Project Athena [1] Kerberos is the Greek name for what the Romans called Cerberus, the three headed dog guarding the entrance to Hell. [2] Flames about DES exportability to /dev/null please; we'd prefer to believe John Gilmore's analysis of the laws, but we'd rather not find out the hard way that he was wrong.
mar@ATHENA.MIT.EDU (03/03/88)
I can't promise RFC conformance, but there is a way to make the Berkeley r programs secure, and at least this change is documented. I'm talking about the Kerberos authentication service. It was developed at MIT by Cliff Neuman, Jeff Schiller, and Jenifer Steiner among others, and is a trusted third-party key distribution system, as described by Needham and Schroeder. It allows a client and a server to both authenticate the entity at the other end of a connection, and to exchange a session key which may be used for encryption. Passwords are never sent over the network in cleartext. MIT's Project Athena has local versions of all of the Berkely r programs that attempt to exchange Kerberos authenticators, before falling back to the old-style authorization of .rhosts files. For more info, see "Kerberos: An Authentication Service for Open Network Systems" in the Winter 1988 Usenix Proceedings, or send mail to steiner@ATHENA.MIT.EDU. The new vesion of the code is going into beta release now, and will be generally available later this year. -Mark
JBVB@AI.AI.MIT.EDU ("James B. VanBokkelen") (03/03/88)
Unix has a near-equivalent of the RSH protocol in rexec(). One difference is the port number (rexec() uses 512, RSH uses 514). The other is that rexec() always requires a password, where RSH has no mechanism for one. We include a client program for rexec() in our DOS PC package, and I wrote a primitive client program for Unix (that uses the library function). It amounts to about 50 lines of code. We support the PC version because we feel the security hole gets even worse when single-user PCs are involved. As far as RFCs go, I don't know of any equivalent simple remote execution protocol described by an RFC, and the only documentation for the 4BSD protocols that I know of is in the man pages. James VanBokkelen FTP Software Inc.
wcs@ho95e.ATT.COM (Bill.Stewart) (03/03/88)
In article <23511@hi.unm.edu> cyrus@hi.unm.edu (Tait Cyrus) writes:
:The reason I am interested in something other than rsh is because
:here at UNM we are strongly considering disallowing the r* programs
:(rsh/rcp/rlogin) because they do NOT conform to the RFC's
:[(machine name case independent).]
:as well as being BIG security problems (.rhosts).
My big gripe with the r* programs is that they lose UNIX semantics.
For instance, rsh doesn't return the condition code from the remote process -
rsh foovax false
returns true if the connection succeeded. Less important but harder to fix,
rsh is non-interactive; I've gotten real used to Datakit's remote execution
capabilities ("dk other3b /bin/ksh"). It would also be nice to have a
convenient rcp-variant that didn't update modification times.
I'm less bothered by machine-name-case dependence - r* are specifically
UNIX utilities, and case dependence is appropriate. (By contrast, HP's
NS-9000, NS-VAX, NS-etc. utilities are supposed to be transparent between
systems; it took us several days of cable-testing to find that the 350
didn't accept it's name in uppercase, as generated on a VMS microvax.)
--
# Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcskarels@OKEEFFE.BERKELEY.EDU (Mike Karels) (03/03/88)
> I am looking for PD version of code that accomplishes the same thing > as rsh but conforms to the RFC's (machine name case independent). > We have users who like to pipe BIG jobs from one machine to another > machine via rsh's. Conforms to *what* RFCs? In particular, machine name case independence isn't the subject of any RFC, and has no bearing on remote login or execution facility protocols or specification. It's a user-interface issue. Incidentally, when using the nameserver for hostname lookup, this interface *is* case insensitive. You seemed to have picked upon the most trivial of criteria for judging such protocols and implementations. (None of the above should be construed as defense of the rlogin and rsh facilities. The main reason that I haven't made any attempt to document these "protocols" publically is that it might help to keep them from proliferating. I've been lobbying a few people to try putting a few options into telnet that would give it every capability of rlogin and many more, so that we could toss rlogin out. The current wish-list is negotiation of local or remote flow control, automatic user-name propagation and login, and maybe even exporting the Unix environment, which rlogin doesn't do either. Sun's "on" program does this, but I haven't looked at it much. Automatic switching between character and line mode with local echoing may be a win, and can already be done by our current telnet clients.) > The reason I am interested in something other than rsh is because > here at UNM we are strongly considering disallowing the r* programs > (rsh/rcp/rlogin) because they do NOT conform to the RFC's as well > as being BIG security problems (.rhosts). The .rhosts file isn't the problem; you're picking on the wrong things. However, see the reply about Kerberos. Mike
dzoey@TERMINUS.UMD.EDU (03/04/88)
> Less important but harder to fix, rsh is non-interactive;
There's nothing in the rsh/rexec protocol that says it's not
interactive. It is possible to write your own rsh/rexec program that
accepts and issues character i/o. After all, rsh/rexec protocols just
describe how to establish data streams and do some trivial
authentication. If you invoke an interactive process with your rsh
command you can do interactive processing (with some exceptions).
Certain programs (like more) will not work correctly since there is no
terminal attatched. Rsh/rexec are not virtual terminal protocols
and the BSD server does not establish a pty for the process.
Programs will work if they only look at environment variables for
terminal information.
I've only tried this in a BSD (or derivitive) environment. I don't know
how other OS's handle rsh/rexec requests.
Joe Herman
PC/IP project.
The University of Maryland
dzoey@terminus.umd.edujerry@oliveb.olivetti.com (Jerry Aguirre) (03/05/88)
In article <2028@ho95e.ATT.COM> wcs@ho95e.UUCP (46323-Bill.Stewart,2G218,x0705,) writes: >My big gripe with the r* programs is that they lose UNIX semantics. >For instance, rsh doesn't return the condition code from the remote process - > rsh foovax false >returns true if the connection succeeded. This is a real anoyance when writing automated procedures. I did find a work around though. Run something like: rsh foovax "command && echo CMDOK" | grep CMDOK The returned status will now be that of the grep and will reflect the success of the remote (but not its actual status). This is good enough for scripts that need to check command success on remote systems. > Less important but harder to fix, >rsh is non-interactive; I've gotten real used to Datakit's remote execution >capabilities ("dk other3b /bin/ksh"). I don't understand what you mean by non-interactive. Certainly there is no tty or terminal type so screen oriented editors and such don't work. But I frequently run "rsh foovax sh -i" when I need to poke around on another system. Certainly that qualifies as interactive, at least as compared to batch. Certain programs do cause problems as they buffer their I/O when run under rsh but enough work for examining or fixing file modes, ownership, and such. > It would also be nice to have a >convenient rcp-variant that didn't update modification times. It wasn't all that long ago that "cp" acquired its "-p" option. In practical terms I usually find that I want to move multiple files and preserve more than even "cp -p" does. I usually run: tar cF - files ... | rsh 'cd dir && tar xpF -' This keeps dates, ownership, directory, and link structure. And then there is "rdist". Jerry Aguirre
dannyb@kulcs.uucp (Danny Backx) (03/10/88)
In article <23511@hi.unm.edu> cyrus@hi.unm.edu (Tait Cyrus) writes: > >I am looking for PD version of code that accomplishes the same thing >as rsh but conforms to the RFC's (machine name case independent). >We have users who like to pipe BIG jobs from one machine to another >machine via rsh's. > >The reason I am interested in something other than rsh is because >here at UNM we are strongly considering disallowing the r* programs >(rsh/rcp/rlogin) because they do NOT conform to the RFC's as well >as being BIG security problems (.rhosts). You might want to look at the "rex" service in SUN's RPC package. This is something quite similar to rexec(3) and rsh(1). What I mean is : it also doesn't provide a virtual terminal for your remote processes. If you have access to SUN manuals, look at on(1c), rexd(8c), and rex(3r). If not, you could get the idea by looking in the RPCSRC 3.9 package, which was recently posted to the net (comp.sources.???). It is also accessible via anonymous ftp and via Email from the archives of Sun-Spots. If you need better authentication than BSD's r*, I think this may do : the rex-system uses the same "UNIX-style authentication" that the entire RPC package uses. If you have a SUN or a 4.3 system from Mt.Xinu, you should be able to use it right away. Danny Backx -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Danny Backx | mail: Katholieke Universiteit Leuven Tel: +32 16 200656 x 3537 | Dept. Computer Science E-mail: dannyb@kulcs.UUCP | Celestijnenlaan 200 A ... mcvax!prlb2!kulcs!dannyb | B-3030 Leuven dannyb@kulcs.BITNET | Belgium
wesommer@athena.mit.edu (William E. Sommerfeld) (03/11/88)
In article <102@icarus.kulcs.uucp> dannyb@kulcs.UUCP (Danny Backx) writes: >If you need better authentication than BSD's r*, I think this may do : >the rex-system uses the same "UNIX-style authentication" that the entire RPC >package uses. Have you actually looked at what `UNIX style authentication' is for Sun RPC? The client puts its hostname, userid and group set in the packet; the server is expected to take the client's word for it, and usually does. Calling Sun's rex, with UNIX style authentication, ``more secure than rlogin'' is like calling a Medeco padlock on a paper bag more secure than a Master padlock on a cardboard box. Sun may have a `secured RPC' version of `rex' in release 4.0 which would be more secure than rlogin/rsh, although not quite as secure as a modified rsh using Kerberos (the MIT/Athena authentication system). Bill Sommerfeld MIT Project Athena.
dannyb@kulcs.uucp (Danny Backx) (03/14/88)
In article <3647@bloom-beacon.MIT.EDU> wesommer@athena.mit.edu (William E. Sommerfeld) writes: >In article <102@icarus.kulcs.uucp> dannyb@kulcs.UUCP (Danny Backx) writes: >>If you need better authentication than BSD's r*, I think this may do : >>the rex-system uses the same "UNIX-style authentication" that the entire RPC >>package uses. > >Have you actually looked at what `UNIX style authentication' is for >Sun RPC? > >The client puts its hostname, userid and group set in the packet; the >server is expected to take the client's word for it, and usually does. I know the original system from Sun is far from secure. You can make it MUCH better, though. You can always check : 1) does the client have a port nr. < 1023 If not, throw this request away 2) is the host the client is sending from one of a selected set of 'trusted' machines. If not, throw this request away I can think of two possible ways to break into this : 1) put a machine on the net who believes he is somebody else This can be detected by the other machines, though, especially the one that the fraud pretends to be. 2) the user trying to break in already broke the protection on the machine he is sending from. I don't think defense against this is possible. I'm sure Kerberos is better... I only wanted to state that rex could be used. Danny Backx -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Danny Backx | mail: Katholieke Universiteit Leuven Tel: +32 16 200656 x 3537 | Dept. Computer Science E-mail: dannyb@kulcs.UUCP | Celestijnenlaan 200 A ... mcvax!prlb2!kulcs!dannyb | B-3030 Leuven dannyb@kulcs.BITNET | Belgium
romkey@kaos.UUCP (John Romkey) (03/15/88)
In article <1188@kulcs.kulcs.uucp> dannyb@kulcs.UUCP (Danny Backx) writes: >I know the original system from Sun is far from secure. >You can make it MUCH better, though. > >You can always check : > 1) does the client have a port nr. < 1023 > If not, throw this request away "Trusted ports" (when port numbers less than 1024 can only be used by a trusted user) exist only in the world of the Berkeley UNIX TCP. Virtually no TCP/IP implementations that are not derived from BSD UNIX have the concept of "trusted ports"; they will allow any user program to open a connection on any port that isn't already in use. Some of the non-BSD TCP's also support rsh; I know of at least one. Rsh is a simple enough protocol that you can bring it up pretty easily on non-UNIX systems. It's useful enough that it's desireable to do so. Trusted ports are a phenomenally bad idea in a heterogeneous environment where you really want security. Even in a homogenous environment of all BSD systems, if some are being used as personal workstations chances are that their users can easily boot them in single user mode and run programs as root. They shouldn't be depended upon to do anything other than provide security holes. -- - john romkey ...harvard!spdcc!kaos!romkey romkey@kaos.uucp romkey@xx.lcs.mit.edu
mouse@mcgill-vision.UUCP (der Mouse) (03/17/88)
In article <23511@hi.unm.edu>, cyrus@hi.unm.edu (Tait Cyrus) writes: > I am looking for PD version of code that accomplishes the same thing > as rsh [...]. The reason I am interested in something other than rsh > is because here at UNM we are strongly considering disallowing the r* > programs (rsh/rcp/rlogin) because they do NOT conform to the RFC's > [as previously indicated, the non-conformance in question is > case-sensitivity of hostname lookups] Why is this a disadvantage? The nameserver does case-insensitive lookups; why should the user program have to care? > as well as being BIG security problems (.rhosts). If this is a problem at all, it's a problem with your user community. They won't create .rhosts files unless they care more about convenience than security, and if that's the case, nothing you do will help (assuming you've educated them in the security holes implicit in creating .rhosts files). People are almost always the weakest link in any security system. You can "fix" the hosts.equiv and .rhosts "problem" very easily by running this every night: rm -f /etc/hosts.equiv < /etc/passwd awk -F: '{printf("rm -f %s/.rhosts",$6);}' | sh der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu
barmar@think.COM (Barry Margolin) (03/19/88)
In article <722@kaos.UUCP> romkey@kaos.UUCP (John Romkey) writes: >"Trusted ports" (when port numbers less than 1024 can only be used by >a trusted user) exist only in the world of the Berkeley UNIX TCP. >Virtually no TCP/IP implementations that are not derived from BSD >UNIX have the concept of "trusted ports"; they will allow any user >program to open a connection on any port that isn't already in use. This is why the Unix RSH server also checks the host against a .rhosts file. Presumably you would only list machines that implement the trusted port rule. Barry Margolin Thinking Machines Corp. barmar@think.com uunet!think!barmar