MOO-cows Mailing List Archive
Re: [SERVER] Secure VM
In an attempt to provoke more discussion (so far successful) and hopefully
an implementation (no word yet, hint hint...) on this topic, I wrote:
>> (1) Security.
>> Limit string and list lengths to prevent malicious programmers
>> (or unfortunate accidents) from bringing down any MOO currently in
Amy Bruckman wrote:
> Yeah, in addition to being able to bring down the MOO accidentally or
> malicously, really long properties can cause killer performance problems. We
> recently had an intermittent lag problem. We traced it to a listening device
> that was adding everything it heard to a list, and had grown to almost 5000
> items long. Whenever anyone was in that room, the whole MOO slowed down.
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
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... (?)
In any case, I didn't mean to indicate through my short
(and incomplete) description of the issue that it's going to be easy to
solve. Honestly, I'd bet it's harder than doing JIT compilation of MOO
code for a particular target machine. But it would be a Good Thing
to have, IMHO. A Necessary Thing. Surely some of the server internals gurus
out there can whip up even a partial solution to this thorny poblem??
Also, to address the other points brought up so far:
Christopher Unkel wrote:
> The problem with this is that it essentially removes a layer of
> abstraction: now any piece of code that manipulates lists or strings
> suddenly needs to know how long it should let that list/string become,
> which probably depends on the permissions of the programmer, etc.
and Andrew Bakun wrote:
> I don't really like this idea tho, since I don't want to have to calculate
> how large my lists are going to get before I start creating them. And of
> course, you'd have to allow wizard override of this, but that doesn't fix
> the "accident" problem. This will just be one more thing that needs to be
> taken into account when porting code; will the lists that this ported code
> from YMOO create fit into the size allowed on XMOO? You'd have to set it
> relatively large in order to get it to not max out on some of the relatively
> smaller operations, but then this goes against having this limit in place in
> the first place.
Look guys, do you always preflight the number of ticks your code will
take? Or correctly handle cases in which you (or verbs you call) violate
the max recursion depth limit?
Both of these (essentially time) limits currently exist, mainly to stop
runaway tasks from recursing or running forever, and both limits can be
changed from one db to another. We need space limits as well, to ensure
that runaway tasks don't consume all available memory. In practice, most
code will probably not need to worry about these limits any more than
they need to worry about tick limits or recursion limits.
Andy Bakun also wrote:
> I don't see this as a way to fix this "malicious programmer"/"accident"
> problem. I could easily work around this limit. Code that, say, raised
> E_QUOTA, when a value got to large could put some objects/the database in an
> inconsistant state (of course, this is what try/finally is for, but I don't
> want to wrap everything in a try finally for when my variable's sizes reach
> the limit. :) ).
> Please make this limit optional.
I didn't really understand this point, unless you're just saying that the
bulk of existing code would not work well if it encountered an
$exception.list_too_long ? The same is true for time limits, and
in fact I've had it happen myself where after changing (sometimes even
increasing!) fg_ticks/seconds or bg_ticks/seconds that code such as
this.some_flag = "on";
"do some time-intensive stuff here which unfortunately runs out of time";
this.some_flag = "off";
causes things to end up in an inconsistent state because something runs
out of time in an unexpected place.
Space-intensive operations should be limited just as time-intensive ones
are, and the programmer can surely recognize where such operations are
located and wrap them with try/finally appropriately. And in the event that
$exceptions are implemented (see previous post), you could even get a
meaningful error such as $exception.list_too_long encountered in line
I'm not talking about $server_options.max_list_length = 20, but rather
20000 or more. Just so that there is *some* limit -- even an approximate
limit would be better than nothing.
Subject Index |