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

"Robert J. Brown" (rj@eli.wariat.org)
Tue, 18 Mar 1997 22:53:57 -0600

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    ------- 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 -------