[DGD] Melville under the Kernel Lib

[Felix A. Croes]

Noah Gibbs <noah_gibbs at yahoo.com> wrote:

>   You've provided a great way to limit processor use and stack use
> (rlimits) for guest scripts.  You've provided a good way to vet most
> privileged operations (secondary AUTO objects).  You've provided ways
> to limit use of call_outs, cloning of objects and other things that can
> cause problems.  All of this is very good, and some is impossible
> without language support.  Well done.
>
>   However, I see one remaining obvious attack on DGD and I don't yet
> see how to address it.  Imagine you provide builders with the ability
> to write an object or the equivalent, such as the Kernel Library's code
> command.  The obvious attack on DGD would be to allocate an array, put
> big strings in N-1 of its elements, allocate another array, put it into
> the final element, and recurse.  In other words, produce an object out
> of things other than heavyweight DGD objects, and make sure that object
> is very large.
>
>   If that's true, won't the object take an unbounded number of sectors?
>  If it does, DGD will run out of sectors and halt.  Not crash exactly,
> but it won't stay up and running, either.

There is no need to wait for DGD to run out of sectors.  It will run out
of memory, and crash.

This is part of the LPmud heritage.  The attack in its classical form is

    str = "foo";
    for (;;) {
	str += str;
    }

DGD has a limit on string length, which helps to prevent accidental
mistakes.  But there is no good way to stop this attack in the mudlib,
unless you go the LPMOO route.  Otherwise it would require driver
support, and even then it would get very tricky.  The driver would have
to know about resource owners, not just for objects but for individual
strings and arrays.  An attacker could probably still cause significant
problems for a mud by staying just within the limits, or by causing this
to happen within badly-coded objects owned by other people.  To prevent
the latter, a completely different runtime model would be needed, such
as the process model in Unix.

I used to worry about this, but in the end I decided that LPC's
object/runtime model just doesn't lend itself to this type of security.
Instead, I concentrated on making it easier to identify an attacker
(or bumbling programmer) with object ownership and file security.

To sum it up: either trust your guest programmers, or give them only a
very limited, sandboxed environment.

Regards,
Dworkin
_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd