MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

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

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 
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...  (?)

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 
such-and-such.

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.

michael
brundage@ipac.caltech.edu
Follow-Ups: References:
Home | Subject Index | Thread Index