Re: [SERVER] Secure VM

• Date: Tue, 12 Nov 1996 07:58:49 PST
• From:
  sting@linguist.dartmouth.edu (Michael J. Fromberger)
• Content-Transfer-Encoding: 7bit
• Content-Type: text/plain; charset=US-ASCII
• In-Reply-To: <Pine.SOL.3.91.961111154450.21044F-100000@laurel> from "Michael Brundage" at Nov 11, 96 04:20:53 pm

quoth Michael Brundage:
> 
> Hmm, was it that Markov chainer I left sitting around? (...attempts to 
> look nonchalant...)  :-O
> 
> Well, here are some of the items brought up so far:
> 
>   Limit string lengths
>   Limit list lengths
>   Limit property lengths (Amy)
>   Limit number of properties on an object (Chris)
>   Limit list depths (Andy)
>   Limit task resources [memory]  (Andy)
> 
> I don't know how many of these (or what other security checks) have to be 
> implemented to make it impossible to Joe Random Programmer to bring down 
> the MOO (accidentally or on purpose), but I think that as long as this 
> can be easily done, MOO (as a tool for network collaboration) is seriously 
> limited.
> 
> Some of these, I suspect, could be added without too much agony (despite 
> earlier claims to the contrary), especially the first four limits listed 
> above (?).  Limiting the amount of memory any given task takes, is nearly 
> impossible to do, but maybe a reasonable estimate could be made...  (?)

It seems to me that we are leaving out a couple of important
abstractions if we're looking for ways to improve the ability of the
MOO server to withstand malicious and erroneous code.  In particular,
the protection domains are very limited, making any effort to restrict
dangerous activities problematic at best.  Rather than simply imposing
an arbitrary system-wide set of limits (whether settable or not), it
seems to me that we should consider segmenting or augmenting the
access domains.

The current access model is user-centered; that is, the permissions a
person has depend solely on what that person "is" -- a wizard, a
programmer, or a normal.  There is the somewhat artificial distinction
made for "builders" but from a system perspective, that's largely
irrelevant.  Perhaps one way to get around the problems we've been
discussing here would be to move toward a 'resource-centered' access
model.  In other words, resources (such as access to built-ins,
various programmatic limits, etc.) would be grouped into categories
such that the accesses for each category could be distributed
independently.

Of course, this would be a massive endeavour, and would have to be
approached very carefully so that existing usage could be reasonably
supported (or at least simulated).  I guess my overall point is that I
think it will end up being virtually impossible to protect against the
malice (or even the accidental errors) of a programmer, under the
current model of access permissions.

Just another sandal in the works... :)

Cheers,
-M

-- 
Michael J. Fromberger
Thayer School of Engineering Unix Group
Dartmouth College, Hanover, New Hampshire, USA
Fromberger@Dartmouth.EDU / sting@linguist.dartmouth.edu

• Re: [SERVER] Secure VM
• From: Michael Brundage <brundage@laurel.ipac.caltech.edu>

• Prev: Re: [SERVER] Secure VM
• Next: Announcing Cup-O MUD
• Index: MOO-cows
• Thread: MOO-cows