[brundage@laurel.ipac.caltech.edu: Re: security]

• Date: Tue, 18 Mar 1997 22:53:57 -0600
• From:
  "Robert J. Brown" <rj@eli.wariat.org>

------- Start of forwarded message -------
Return-Path: moo-cows-errors@parc.xerox.com
Date: Tue, 18 Mar 1997 14:33:31 PST
From: Michael Brundage <brundage@laurel.ipac.caltech.edu>
To: "A.TEAL" <shumat2@pegasus.hud.ac.uk>
cc: moo-cows@parc.xerox.com
Subject: Re: security
In-Reply-To: <46C47B8782F@pegasus.hud.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: MOO-Cows-Errors@parc.xerox.com
Precedence: bulk

On Tue, 18 Mar 1997, A.TEAL wrote:
> As a new wizard, commissioned to set up and run a new MOO for CAL, 
> I'm discussing security issues with personnel who are in a position 
> to kell the project if the security is not to their satisfaction.
> 
> Their particular concern is to avoid players gaining access to the 
> MOO server root and thence to other machines on the network.

As you might have guessed, this is a perennial topic on this list.

You should be able to find some of the previous times it's come up on any 
of the searchable archives of moo-cows; I've heard there's one at
http://eli.wariat.org/mcarc/index.html
but haven't checked it out myself.  Alternatively, use a Web search 
engine to look for "MOO and security"

The short version is this:

The standard, out-of-the-box MOO server cannot access your filesystem.  
There is a compile-time option to turn on outbound network connections 
by default it is off, meaning that the MOO cannot initiate outbound 
connections, and hence cannot cause network problems. (Incidentally, various 
informal studies have indicated that MOO servers are typically not high 
traffic; more of a concern is their process size.)

What MOO users can do is this:

If they have (or gain access to) programmer's priveleges, they can bring 
down the MOO server by causing it to run out of memory.
If they have (or gain access to) wizard's priveleges, or if the MOO has 
security holes, they can access information in the MOO database which 
was intended to be private.

The corollaries are:

Don't store passwords in the MOO that are the same as those used on the 
local filesystem.  (Duh.)
Don't store information in the MOO that you don't mind sharing with any 
of your users (or equivalently, restrict your user base to trusted users, 
or else make sure there are no holes).

If you make modifications to the MOO server, such as installing FUP or 
fileio (file system access packages), then you may create opportunities 
for MOO users to wreak havoc on the local computer system.  So if this is 
a concern, don't do it.

If you enable outbound network connections, then users (with appropriate 
priveleges) could initiate connections from the MOO.  This could create 
problems as they might access remote servers anonymously (e.g., send hate 
mail to someone, and that mail be traced back to your MOO) or they might 
access local servers behind a firewall (but if you run your MOO outside 
the firewall, this won't be a problem).

Furthermore, many people recommend against running the MOO with root 
permissions, though as far as I can see this is mainly as a precaution 
because it is a Smart Thing To Do, and not because it is inherently unsecure.

Of course, your mileage may vary, and I'm not a security expert, so 
believe all this at your own risk.  <Insert rest of standard disclaimer 
here.>


Cheers,

michael
brundage@ipac.caltech.edu
------- End of forwarded message -------

• Prev: [brundage@laurel.ipac.caltech.edu: Re: dictionary server?]
• Next: [cunkel@us.itd.umich.edu: Re: Modifying player properties based entering any command]
• Index: MOO-cows
• Thread: MOO-cows