[DGD] Re: Net Security

[Logic]

On Tue, 17 Mar 1998, Sten Lindgren wrote:
> In my experience there is always one more security flaw that can be
> exploited, and there will be those who try to explot them.

One could then argue that connecting a machine to the Internet opens up
the potential for innumerable security issues, and that OS vendors who
support this functionality are being irresponsible by opening such a
potential security problem for the user.

People connect to the Internet everyday, you'll note, and quite
successfully. Just as people use interpretive languages like DGD's LPC for
doing basic networking everyday.

You would recommend, based on fear of your own skills, that others not
make informed use of these features?

> Personaly I would not allow any mud that can initiate outgoing
> connection on any system Im resposible for if I do have a say in the
> matter. It might become a very tempting place to initiate an attack on
> other systems for some people, and those attacks would be traced back to
> the mud (if traced at all).

This is not a failing of the technology, but a failing of the people using
it. Do you run a mail server on systems that you administer? It might
become a very tempting place to initiate an attack on other systems for
some people (such as spam relaying, etc), and those attacks would be
traced back to your mail server.

But, you say, I prevent mail relaying through my system! Good for you. Are
you now claiming that it's impossible to secure a similar system (a mud) 
which is used just as frequently, by using appropriate security
safeguards?

> Of cource this is my point of view, and Im personally very happy Dworkin
> decided not to include any net package in his driver, the day that should
> happend I would hope the feature could be turned off.

Now this is a sensible idea. A runtime or compile-time option for
disabling the networking code would make those who use it very happy (it
would finally have the official "stamp of approval" that they have been
craving), and those who don't want it could simply disable it. This might
require some restructuring of the code, but the benefits might well
justify the effort.

> As for services like SMTP and FTP they can be implemented using external
> written programs that initiates a connection to the mud if it needs some
> data from the mud itself (like acess permissions or whatever).

Let's take the SMTP model a little bit farther: you implement an external
SMTP gateway for the mud. It opens a connection to the mud itself (logging
in as a special virtual user, for example), and communicates incoming
email to the system (by some mechanism of bolting up to the locally
installed email backend. It also receives outgoing email from the mud,
injecting it into the local email backend, or directly delivering it
either to a smarthost, or to the target system itself.

At this point, can you honestly say you've done anything different than
native LPC network access? You've just increased the time it will take to
implement (since you'll be spending a lot of time writing an external SMTP
gateway) and you'll still have the same potential for abuse that native
functions would allow (since you now have a two-way channel to a process
running on the local system, which could potentially be bug-ridden). How
is this different than simply providing networking primitives to the
administrator, and charging them with the responsibility of securing their
system appropriately, which they would NEED TO DO ANYWAY?



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.

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.

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.

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.

Or do you have other motivations that we aren't aware of? :-)

(The smiley isn't sarcastic, btw...I'm genuinely curious if there's
something I've missed here.)

-- 
  _ ____ ____________________________________________________________________
 / /___/\__                                                                  \
/  \   \ \/\  logic at logic.net                                                 \
\   \   \  /  http://www.logic.net/~logic/                                    /
 \___\___\/__________________________________________________________________/






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