[MUD-Dev] Scripting languages

[Jay Carlson]

On Sun, 2003-06-29 at 06:11, Mark 'Kamikaze' Hughes wrote:

>>>> While it's working the other way around, using a scripting
>>>> language for the entire MUD, the very badly-named POO (Pythonic
>>>> MOO) is a nice engine, and fairly small--an earlier version I
>>>> have somewhere around here is even smaller, and still provided
>>>> all the necessary MUD services.

>>> Python supplies an awful lot of handy default libraries which
>>> tend to make the code fairly small.

>> ...most of which can't be used without a security audit, if you
>> don't have full trust in people writing code.  The mutability of
>> basic Python data types is just the beginning.

> That's partially true, but hasn't been a significant problem with
> Zope, for instance.  Zope's restricted sandbox environment is,
> AFAIK, completely secure; there have been security alerts and
> fixes, but no major exploitation of them.  There's also currently
> work on a new general sandbox environment for Python, since rexec
> had problems.

Sandboxing is OK, but is not really comparable to what you get with
MOO and related systems.  What you really want is a system that
allows multiple authors with differing degrees of trust in each
other to write code that can interact safely with each other.

(OK, that may not be what *you* really want, but it's what I really
want.)

Sandboxing does well in situations where there are clearly defined
"high" and "low" sides.  The fun starts when you have lots of "low"
sides that should interact.

Also, it would be nice if I didn't have to think about security
every time I wrote a line of code.  I can do that, but it's no fun.
It's very hard to write large systems under that kind of pressure.

> There are security and malware questions in using *any*
> general-purpose programming language for scripting; if you can't
> violate security or create an infinite loop within the language
> proper, you can overrun buffers, or find some other abuse.  There
> have been known security holes in Lua, as well.

I don't believe the situation is hopeless, nor do I think that all
of these should be lumped together.  There hasn't been a known priv
elevation attack on the MOO server for many years, much less a
native code exploit.  This leaves the core (mudlib) and some of the
cores have been audited in some detail.

The remaining attacks are DoS; the biggest one is memory exhaustion,
but it leaves a giant arrow pointing at the perp.  Infinite loops
aren't a problem, as MOO enforces tick limits; overrunning network
output buffers results in the server dropping them on the floor and
warning you.

Which Lua security holes are you thinking of?  The only one I
remember involves creating malformed bytecode, and I think a
mud-like system is unlikely to accept remote bytecode anyway.

However, the creation of something MOO-like in Lua would involve the
creation of new security infrastructure written in Lua, and that
would have to be carefully examined.  No free lunch.

> And on the gripping hand, it doesn't matter, because the only
> people you'll normally allow to write full scripting code *are*
> trusted admins.  The MUDs where this is not the case are fairly
> unusual, and already have their own scripting languages.

Do you trust them to merely mess up the game, or to take over the
machine?

--

Jay Carlson <nop at mitre.org>
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev