Newsgroups: comp.parallel.pvm
From: manchek@thud.cs.utk.edu (Bob Manchek)
Subject: Re: Q: PVM Network Communication Behavior
Organization: Computer Science Dept, University of Tennessee, Knoxville
Date: 2 Oct 1995 21:18:21 GMT
Message-ID: <44pkutINNmho@CS.UTK.EDU>

In article <44f4kh$hk0@elroy>, bode@hubris.jpl.nasa.gov (Andy Boden) writes:
|> Greetings from Southern California,

Howdy,

|> I have a question for the real network gurus/PVM hackers.  This
|> question, or its answer, has far-reaching implications for anyone who
|> "mines cycles" on machines who are administered by folks who take
|> their security seriously.
|> 
|> Recently I ran into a problem starting PVM (v3.3.7) on some machines
|> that had previously worked fine (and were among the most productive in
|> my ensemble).  These machines were all in a single subnet, and all
|> managed by the same set of system manglers.  Through trial and error
|> we narrowed the culprit down to a set of implemented security
|> "features" that carefully controlled the types of TCP packets that
|> were recognized and acknowledged by these hosts.  So I contacted the
|> manglers to verify this speculation, and this is in fact the case.
|> 
|> Because the sysadmins were friendly folks, they were willing to help
|> me figure out exactly what PVM was trying to do, and what "holes" in
|> their security procedures would be required for me to get back to
|> work.  The following is a description of the network behavior of PVM
|> during startup and nominal operation made by such a sysadmin.  I
|> believe it to be correct, but I'm not particularly well qualified to
|> judge (I'm a physicist):
|> 
|> > Working interactively with Andy on configuring a filter hole for PVM
|> > from his machine I first tried both ports 512 (rexec) and 513
|> > (rlogin).  That did not work so I then opened a hole to allow all
|> > packets from hubris and captured them.  PVM apparently uses rexec to
|> > negotiate "random" ports above 1023 for data and command transfers.
|> > It also uses both TCP and UDP on these negotiated ports.  This
|> > behavior makes it impossible to set up a decent protocol filter.
|> 
|> This description of PVM behavior, presuming it's correct, makes my
|> security conscience sysadmin unhappy.  Presumably this prevents him
|> from simultaneously allowing me access and minimizing his security
|> risk if my machine is compromised.

That's basically right.  PVM uses rexec (and rsh) to start manager
processes (pvmds) on new hosts in the virtual machine.  PVM programs
(tasks) and pvmds communicate between hosts over both TCP and UDP
sockets bound to random (system-assigned) port numbers on these hosts.

|> So now I (finally) come to my questions:
|> 
|> 1) Is there some way to control this connection behavior, say for
|> instance, that I define at pvmd startup the port number that PVM uses
|> for command and data communication?  This would allow the number of
|> enabled ports to be limited, minimizing the risk for unintended
|> access.

I think you'll need more than one port per host, but you could
conceivably hack the PVM code to pick from a restricted list of ports.
Right now, it calls bind() with a port number of zero in a few places.
You could insert a loop to pick a free port from, say, 8000..8009
or any restricted range you want.

The reason you'll need multiple ports is that you may have several
processes on each host trying to talk to each other.  It would be tough
to have them all bound to the same port number.  If you're willing to
not use direct routing (PvmRouteDirect) you'll only have to contend
with a single socket for each pvmd(host).  It would be easy to force
the code to bind the pvmd's UDP socket to any port you want.  You may
have run into trouble if you have more than one PVM user per host.

So, you could restrict PVM to one port with some loss of efficiency.
Or to a range of ports, but that probably doesn't buy you much except
that if something was found to be using those numbers, it would more
likely be PVM :-)

|> 2) Is UDP a requrement for PVM functionality, or is there some
|> compile-time or run-time switch that one can use to only use TCP in
|> PVM communications?

Yes, pvmds (manager processes) communicate over UDP.  There's no
compile option.  It probably wouldn't be too hard to hack PVM to use
TCP instead, but it wouldn't be as simple as just replacing all the
SOCK_DGRAMs with SOCK_STREAMs.

|> 3) Is such unsecure communication behavior a "feature" that has been
|> /is likely to be removed in PVM releases later than v3.3.7?

We have no plans to remove it.  If somebody has a great idea...

It's not clear what you mean by "unsecure communication".  PVM is
reasonably secure (about as much as most IP-using applications).  Of
course, that's not enough for everyone.

PVM entities (the managers and libpvm library) don't accept connections
or packets from random locations.  A virtual machine is "grown" from a
single pvmd process, and legal socket addresses are passed over
already-established channels.  That is, local authentication between
process and pvmd is done by the filesystem.  Remote authentication (to
start new pvmds) is done by rexec/rsh.  New socket addresses are sent
over these connections.

Bear in mind that restricting use to certain ports is a pretty crude
way to do network security.  Why prevent outsiders from sending packets
to port 7000, where there's probably not going to be anything
listening, if you're still going to allow packets for things like
rlogin and rexec, where there will be something listening and happy
to give you a shell?

Lots of other programs build socket connections in the same way.  It's
common to create a socket and connect() it, without specifying the
local address (allowing the system to choose a free port).  It's often
possible to find out what a connection is doing, however, because one
end _will_ be to a well-known port, e.g. login.

Portmap, used for RPC services, works like this too.  The portmap
daemon is bound to a well-known port on a host, but other RPC services
are not.  To find out the port number of a server, you first contact
port mapper.

|> 4) Is MPI better behaved in this network access respect?

Dunno.  Depends on which implementation you're considering.

ok,
b
-- 
/ Robert Manchek                University of Tennessee     /
/                               Computer Science Department /
/ (423)974-8295                 Ayres Hall #104             /
/ manchek@CS.UTK.EDU.           Knoxville TN  37996-1301    /
/     http://www.netlib.org/utk/people/BobManchek.html      /


