[DGD] Re: Net Security

[Felix A. Croes]

Logic <logic at logic.net> wrote:
>[...]
> Dworkin, this is my first and last post on this subject, since this has
> doubtless been argued at extreme length in the past: DGD gives an
> administrator an incredible amount of rope with which to hang themselves
> (and hence is already immensely helpful already to anyone who would relay
> an attack through their system) by the sheer level of programmability
> inherent in it. Surely the ability to interact with the network is just as
> much a potential security problem as any other code in the system, if
> improperly managed.

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.


> If it is a concern of image for you (someone breaching security on a DGD
>  and causing problems), surely this kind of thing isn't -your-
> problem to shoulder?  It's a problem for the administrator who simply
> wasn't apt enought to understand the implications of their personal
> security choices, but not for DGD itself. DGD simply provides a set of
> tools to develop a project with, not the ineptitude of an administrator
> who doesn't know better.

An sysop who runs sendmail does not choose to have his system hacked.
A user who runs X on his machine does not choose to open himself up to
the latest security leak.  Neither the sysop nor the user can be called
inept in their security choices; they are, however, responsible for
using buggy software that can be abused in this manner (or for not
informing themselves about this aspect of the software).

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.  I take it as my responsibility that DGD
will indeed perform in this manner -- and really, it is up to me to
determine what DGD does or does not provide.  If 90% of the muds
using DGD extend it with the networking package, that is the
responsibility of the administrators of the respective muds.  As DGD
is a successful commercial product, the distinction is not unimportant.


> We're talking about a relatively basic language feature: a network layer
> interface. Find me another language that doesn't implement network
> primitives. No, the "everyone else does it, so we should" argument doesn't
> fly well with me either. But it is certainly worth passing consideration.

Now you are letting your rhetoric get the better of you (compare "find
me another language..." with "most other languages" below).

I suppose that providing a secure system is yet another thing that I
do not want to do like everybody else.  If all programmers were as
concerned about security as I am, we would not have this crappy
internet...


> So, in the interests of those who are arguably incapable of running their
> system securly anyway, you reject a useful and widely adopted feature, one
> which is provided as a core component of most other languages. Interesting
> approach.

I find it curious that you consider the administrators who would accept
the risk posed by a programmable environment with outgoing connections
the more capable.  As for the incapable administrators, I believe I
give them sufficient leeway to make their mud insecure by allowing them
to misconfigure it :)

Regards,
Dworkin