[533] in Coldmud discussion meeting

Re: To-Do list..

daemon@ATHENA.MIT.EDU (Sat Nov 5 16:26:01 1994 )

Date: Sat, 5 Nov 1994 16:22:11 -0500 (EST)
From: James C Deikun <jcdst10+@pitt.edu>
To: brandon@riverheights.declab.usu.edu
Cc: coldstuff@MIT.EDU
In-Reply-To: <9411050631.AA06234@riverheights.declab.usu.edu>

On Fri, 4 Nov 1994 brandon@riverheights.declab.usu.edu wrote:

> caustic nature of this post to heart and read the true intent inside (i.e.
> don't take any offense from the material content which may follow :)

I'll give it my best shot.  :)

> Should be (as in there is a soon to occur change which will make it
> irrelevant), or you think it should be?  If so, why?  I gleaned a touch
> of this off your message but you offered no suitable replacement.

As in I think there should be.  I think the whole error-handling system
should be rewritten, and if that turns out the way it should the syntax
and semantics of the whole thing will be different enough that that
change will become meaningless and impossible by lack of context.

> Hmm, I like some of them, but you are stepping down with others... First:
> 
> <    bind()                    => listen(port, object)
> 
> Could fly, but I would be adverse to the name because 'listen' in general
> is vague.  Listen to what?  Mexican mariachi bands over on object $party?

Could be.  In a way the vagueness is part of what I like about it.

> Perhaps listen_for_connection(), but then you may as well go back to ports,
> which DO have a meaning in TCP but does that necessarily mean that is how
> we are interpreting them?  Perhaps port is just a generic term saying
> something will have a 'berth' here, be it a network connection or some
> type of modem interface.

That's how I see them.

> <    unbind()                  => unlisten_port(port)
> 
> Ouch, rescind into improper english while using an even more vague term
> than 'port'.  The least you would want is stop_listening_on(port).
> (perhaps as the alter aspect of this have start_listening_on(port, object)).

Well, I suppose.  I never really gathered though that programming
languages were meant to be exactly the Queen's English.

[deleted stuff I agree with]

> However, perhaps a buildin of 'ports()' (no args, returns a dictionary with
> each port as the key, and the value being the object bound to said port).

Well, that's one way to handle it.  I'd like to be able to go the other
direction as well, though, without inverting a dictionary.

> (I think I like port better than listen, in the long run--more because that
> is how it is now, and there is no real reason to change it since it does
> say what it is, even in the most abstract circumstances).

Good point.

> Well, the main reason I suggested axing _freq is because I'm not one
> for abbreviations.  Then again I'm not one for long names either.  What
> is wrong with 'set_heartbeat()'?  That is what you are doing (depending
> upon how you define a heartbeat--I would do it as being a periodic
> pulse of some sort, so by setting the heartbeat you are setting how
> often said pulse occurs).

To me, the heartbeat is the pulse or beat itself, and the interval is
a quality of it--how long between successive instantiations of this
phenomenon.  set_heartbeat() sounds to me like one is trying to
specify a different method to call for the heartbeat.

> < This wouldn't work well with something like MOO's NP_SINGLE network
> < module.
> 
> I suppose it is a good thing this is coldmud then? (why wouldn't it
> work with MOO's whatever?  Why does this actually have an effect upon
> the design consideration of implementing such a file structure?).

I think NP_SINGLE is a Good Thing(TM), which *should* be available in
ColdMUD.

NP_SINGLE uses stdin and stdout as a connection, which is reestablished
whenever it is closed.  This allows testing on machines without
networking.  It can't use stdout, though, if stdout is the log.

> < This one is IMNSHO entirely silly, superfluous, and otherwise not a
> < Good Thing(TM).  The idea behind it seems to be that by allowing
> < online changing of methods basic to security one is undermining
> < security.
> 
> How is this such a hard concept to grasp?

The book you sited earlier said 'unauthorized' changing.  How 'online'
is identical to 'unauthorized' is the point that continues to escape
me.

> So you think one should program a security system which you can trust
> in being impregnable?  By leaving the ability in-db that such key methods
> are compilable/writable, the threat that they can be changed is
> *ALWAYS* there, no matter WHAT security precautions you take in-db, you
> always have to assume that it can happen somehow.  If you have the
> ability to lock a key method, then you have just plugged one potential
> hole relatively tightly.

I suppose it would be even better if we burned these methods in ROM on
the server machine.  Then even if someone cracked root on the machine e 
could not change these esssential methods.

There is such a thing as taking a good idea (security) to ridiculous
extremes.

If you have holes in your DB such that people can gain admin privileges,
you're rather screwed anyway.  What I might like to see is an option
where reprogramming of certain methods should be mentioned in the server
log, along with full text and task stack.  This allows essentially the
same level of security, but is not such a damned pain to deal with.  The
flag itself, perhaps, should not be able to be turned off in-DB.  If it
can be this too should be logged.

Note that if you run your server log through a filter that can yell at
the archwiz through the console you'd have a good chance of catching
the cracker in the act before e even realizes it.

> Having a 'lock' flag on a method would add nothing to the direct functional
> security of the method.  What it does do is give you a guarantee that
> somebody else will not find a back door that allows them to completely
> replace said method with their own.  Your assumption that a single method
> can completely protect itself from harm is silly, and quite frankly I
> would have 'grave doubts' about any system which does such a thing.

Like I've said before, if compile() can be protected against actual
calls, these essential verbs can be, unless someone can do an arbitrary
eval on $sys, in which case they don't need any help from overwitten
methods to compromise the security of the system completely.

> < The marginal security gain is simply
> < not worth making a whole bunch of people crawl on their knees
> < through textdumps when maintenance needs to be done.
> 
> It is not hard to edit a textdump.  Infact, I would almost prefer to
> edit a textdump in some instances (do not think in relation to MOO dumps).

It requires taking the server down, it still requires finding the right
place to edit or running things through a huge script, if you don't do
it right the server won't start and you'll have to go back again, etc.
And if a security hole shows up while the archwiz is on vacation nothing
can be done about it.  This is a good thing?

> That would be your option, however such an act would (in my opinion) show
> others how much you care about your system's integrity.  The lock flag
> is not intended to be used on very many methods.  If you wish to spend the
> time to write a perl (why the fk perl?  sed would work just dandy) script

It's hard to say what'll work dandy on what if you're not very familiar
with the actual format of the textdump.

> which strips the lock flag out of the 5 methods in the entire db which have
> it, more power too you (?).

I might have to rewrite a few methods afterward, because of the broken
way the security would be set up.  It would be worth it, though, to have
everything online maintainable.  Any real operating system can be admin-
istered remotely, or at least be set up to be so for a week without
compromising security too much.  Security, important as it is, is only one 
of a group of real-world needs which apply to VESes as much as OSes.

--
James Deikun (James@JHM, James & Splat@BlueMOOn)