[MUD-Dev] about MOO

[Andru Luvisi]

On Fri, 19 Nov 1999, Joey Hess wrote:
[snip] 
> I agree, I've never been comfortable with LambdaMOO's security model. The
> stack based model sounds very intelligent to me, can you elaborate on it a
> bit? Are there any gotchas associated with it?

Put simply: Whenever an object tries to do something restricted (ie read
or write a file) your validator function (part of the mudlib in the two
implementations I'm familiar with, Nightmare/Foundation and TubMud)
examines the current call stack (the same one you'd see if you did a
backtrace).  The functions don't matter, only the objects.  If *all* of
the objects have the needed access, then the operation succeeds.  If *any*
of them fail, the operation fails.  The only time the procedure is
different is if an object specifically chooses to have *only* its access
used for making the decision.  In the implementations I've seen, there was
a function called "unguarded" which you would hand a thunk off to.  Pretty
much any object which needs to save state and interacts with users would
need to use this.  The big example is bulletin boards.

The result of this is that if you just write code, it's secure by default
because it can only do things that both you and whoever calls it can do.
You can't write trojans, because your restrictions apply to it.  Others
can't exploit it, because their restrictions apply when they send function
calls to it.  The only places in the mudlib that become really critical
from an interobject security perspective can be located with a recursive
grep.  Of course, this doesn't fix *every* possible security problem, but
it helps a *log*.

The only gotchas I can think of are:
 Objects used to store commands need to be all powerful, so they can do
 whatever can be done by anyone who calls them.  This means anyone who can
 edit commands has administrative access.  I don't considder this a big
 problem since normally anyone who can edit commands can put in a trojan
 horse and get an administrator to execute it.

 If I'm a normal wiz, and I create a wiztool, other wiz's need to copy it,
 rather than using mine, in order for them to be able to use it to do
 anything restricted.  This can be inconvenient, but it is good for
 security.
 
> > MOO doesn't have a preprocessor.  Opinions are varied on whether this is a
> > good thing or a bad thing.  Personally, I like having a preprocessor.
> 
> If you mean something to preprocess a user's input, this could be added to
> the appropariate method of the base character class. (Perlmoo has a
> preprocessor added in exactly this way.)

I was referring to the C preprocessor, upon which LPC's preprocessor was
based.  

ie:
#define MIN_LEVEL
...
#ifdef MIN_LEVEL
 if(this_player()->query_level() < MIN_LEVEL)
  return 0;
#endif

In my case, I was sharing a huge data structure among everything so I
could save the state of an entire simulation with a single save_object().
I had a half dozen header files with things like:
#define MCBANK state[0][3][1] /* not correct, I just made it up */

where state was an array or a mapping, which was a reference to a subtree
of the global state, shared through LPC's implicit pointer semantics.

Yes, I know it's ugly.  You should have seen the ideas I threw away...

Andru
--
-------------------------------------------------------------------------- 
| Andru Luvisi                 | http://libweb.sonoma.edu/		 |
| Programmer/Analyst           |   Library Resources Online              | 
| Ruben Salazar Library        |-----------------------------------------| 
| Sonoma State University      | http://www.belleprovence.com/		 |
| luvisi at andru.sonoma.edu      |   Textile imports from Provence, France |
--------------------------------------------------------------------------




_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev