[DGD]Default Wiztool not loaded ?

[Felix A. Croes]

Stephen Schmidt <schmidsj at union.edu> wrote:

> On Sun, 18 Feb 2001, Felix A. Croes wrote:
> > That would concentrate security-related code in fewer objects, but it
> > would still require different privileges for commands performed by
> > the same object, depending on what player is executing the command.
> > I consider this a possible weakness, and it has been an actual
> > weakness for many mudlibs in the past.
>
> Agreed - but doesn't the wiztool have a similar weakness?
> For instance, consider the set_global_access() function
> in /kernel/lib/wiztool.c. That function requires different
> privileges depending on who invokes it. The main difference
> that I see is that each different wizard will have a 
> different clone of the wiztool (perhaps each wizard
> having a different file inheriting the kernal wiztool,
> perhaps extending it, perhaps not), but with the command
> bin, all players use the master copy. But why does that
> make a difference? The set_global_access() function does
> not check any of the internal data of the object, except
> for the owner; but how is checking the owner of each individual
> clone so different than checking the identity of the user that
> invoked a command, assuming one uses previous_program()
> to secure each command against being invoked by anything
> other than a user? Surely it is just as easy to fake
> the one as to fake the other?

The "owner" of an object in the kernel library is very similar to a
"uid" in older mudlibs, but there are some differences.  The owner
of an object is not changable.  Once a wiztool object has been created,
it is tied to a particular wizard for its lifetime.  Of course, even a
uid system can eventually be made secure, but it is good for a security
system to have as few points of attack as possible.  


>[...]
> (Side note: Melville appears not to check whether the
> object invoking a call is a user object; it only checks
> whether the user has "admin" privileges. However, "admin"
> privileges can only be assigned to a user object, so
> in fact Melville is restricting access to user objects,
> and indeed, only a subset of those.)

I just checked, and it appears to be fairly simple to break Melville's
security.

 - The function set_creator() is not nomask.
 - Arrange for some code to be executed during another player's
   command (for example, he walks into your room) and you can change
   the creator of an object you made to that player.
 - The creator of any object can be reset to "Driver" from a callout.
 - Call user->set_privileges() from a callout, and the privileges
   are reset to "login".
 - valid_read() does not first resolve the path it checks.
 - valid_write() only resolves the path it checks if called from
   a function called "log_file".

All this from checking /system/auto/security.c -- I'm sure there is
more, but at this point I can already arbitrarily rewrite LPC source
files :-)

Making a mudlib secure is not a trivial task.  General guidelines are:

 - Define the basic system in a small set of mostly static source
   files.  Especially do not put security-related code in often-changed
   files.
 - Have as few points of attack as possible, and make sure you know
   where these are.  Avoid complexity.
 - For new mudlibs, design your security system before anything else.

Regards,
Dworkin

List config page:  http://list.imaginary.com/mailman/listinfo/dgd