[DGD] Changing connect() (network package)

[Felix A. Croes]

bart at wotf.org wrote:

> > > > Not really.  You can let it log on to a special port that is only opened
> > > > on localhost and has its own connection protocol. 
>[...]
> > It also has nothing whatsoever to do with "security through 
> > obscurity". :-)
>
> Oh, the 'own connection protocol' was quite an security through obscurity
> argument.

I can see why you thought so, but I wrote that with hname in mind, and
thought of it as covering the entire connection, not just the login
sequence.  Much of the difficulty with hname was due to the fact that
it connected on an ordinary port, and the namelookup server object it
connected to was not properly shielded from the normal user command
environment.  LPmuds were hacked that way, and that is why I assumed
you brought up hname.


>[...]
> See, I know you don't like outgoing connections, and I agree with the basic
> permise that having guest coders being able to make arbitrary outgoing
> connections is just a really bad idea.
>
> That said, you know as well as I do why I pointed at hname.

Well, I do now.


> DGD initiates outgoing traffic and has done so for quite some time, this in
> order to do hostname lookups.
>
> It serves a purpose, a good one really, and it doesn't allow arbitrary
> outgoing connections.
>
> So, the issue is really not initiating outgoing traffic, DGD does that today.
> The issue is preventing random guest coders from abusing this.
>
> Securing outgoing connections on the lib level at least to the point of not
> allowing random guest coders access to them is no more difficult then
> protecting file efuns such that those random guest coders can't just write to
> your system files.

It is also a matter of liability.  DGD, as I provide it, does not
in itself provide a possible staging ground for attacks on other
hosts, full stop.  Of course, this argument does not have as much
force as it used to, with buffer and heap overflows now being used
to inject arbitrary code all the time, but intention matters.

As to the difficulty, mud security breaches of all sorts happen all
the time.


> That said, I can understand why you don't like them, but I can't see any
> argument as to why an external connection service is a good solution for this
> since it only adds more potential security problems and does not solve a
> single one.

As I see it, if you want outgoing connections you can't be too
concerned about security.  An external daemon is a good solution
for the sake of keeping up with changes in DGD code, not for any
other reason.

Regards,
Dworkin