[DGD] Re: Net Security

[Serhat Sakarya]

On Tue, 17 Mar 1998, Felix A. Croes wrote:

[snip]
> Take vanilla DGD; install it on a disk partition of its own in such a
> way that the entire mudlib tree is on this partition, and the driver
> binary, swap file, state dump file and config file are outside the mudlib
> tree; run the driver with appropriate limitations on memory usage.  Now
> you can be absolutely sure that whatever is being done with DGD, it will
> not affect your machine other than by taking a certain amount of disk
> space, memory, CPU time and network bandwidth.  Your mud might be taken
> over and the auto object could be rewritten to evade the restrictions it
> imposes; and still the mud cannot exceed these known limitations, no
> matter how hard the admin tries to hang himself inside the mud.  Nor can
> it be used to breach the security of your system, or that of any other.

Actually, it might be possible to imagine a system with external
security check (i.e. in the driver) that will not allow connections
to potentially dangerous ports such as 21, 23, etc. Whenever a coder
wishes to access a certain port (on a specified system?), a little
file may be edited (outside the mud tree) that contains a list of
allows hosts/ports/etc. Also, objects that are allowed to perform
these actions may be registered offline (but this may be useless if
these objects can be edited).

Ok ok, some people might start screaming right now, but this would
severely limit a potential threat, even if someone has gained complete
access to the mudlib. Also, severe logging might be quite useful.

> With DGD, it is also a matter of responsibility.  I provide software
> that can be configured in such a way that there is <no way> to exceed
> certain known limitations.

Heh, remember the little bug on the windows version with which you could
gain access outside the mud tree by using \ in the right places? :-)

Anyway, I do agree with Dworkin that as far as security goes, you can't
be careful enough, especially if you're providing a product that a fair
amount of people will trust almost blindly. If anybody knows/remembers
the charming imapd bug that came with the Red Hat linux distribution,
you'll know what I'm talking about :-)

Btw, any development being done (completed?) on the area of making
the driver multi-threading?

Regards,

Serhat Sakarya




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