[304] in Coldmud discussion meeting

Re: log and times

daemon@ATHENA.MIT.EDU (Mon May 23 16:41:16 1994 )

From: BRANDON@cc.usu.edu
Date: Mon, 23 May 1994 14:34:24 -0600 (MDT)
To: coldstuff@MIT.EDU
X-Vms-To: COLDSTUFF

< Take this for example:
<
< hacker logs on, hacker breaks into sys, hacker turns off logging,
< hacker makes an admin character. well, your doing a scan of the logs,
< catch the hack into sys, and patch it. you still have an admin that is
< a hacker running around, and may not see it for a while, especially if
< he hides some things to avoid detection.

OK, lets go over that example (as its basically what I was thinking).  But
first, let me explain what makes a person an admin.  There is a parameter on
$sys which is a list of objects called 'admins'.  If you are in this list, your
an admin.  Now, assuming somebody gets write access to $sys, they then change
$sys.log so it no longer logs times (?) or just so it no longer logs.  Heck,
why even bother with log?  I dont know.  They can just run 'as $sys eval admins
= admins + [me];' and be done with it.  ColdMUD does everything in-db, which
means in general finding loopholes for hackers is easier, but if a hacker does
get access to something they become damn powerful.  I suppose that we could
hack $sys.eval, and every sys method, so that any time anything is _written_ to
$sys (other than things like setting a new connection object, which will be
leaving sys soon anyhow) it is logged, then you could get the last log of
somebody adding themselves to the admin list (if its through eval).  The only
way I can see a hacker getting write access to $sys is through a munged method
on $sys that happens to write to the critical parameter, and this would be the
fault of somebody writing to $sys.  Since $sys is the only object you really
have to look at for mega security it is easy to watch _every_ change to it with
a critical eye and to make sure that the methods it has are tight as a ...
(colorful wyoming phrase involving sheep).  Everywhere else if you gain
security it is just write access to a single object.  By keeping everything
encapsulated _most_ things are relatively local (i.e. they can gain access to
one "system" of objects).  I'm not saying the core it secure, infact I know
that right now you can probably drive a mac truck through a number of security
holes, but in relation to log(), having the server tack time onto each string
is not going to make _ANY_ difference at all.

< Granted this is kinda
< extreme, cus most hackers wont bother to be so sublte on a mud, but it
< is plausable. I dont think logging should be changable at run-time in
< ANY instance, except to hand-add a new log message. Of course, it wont
< kill me because its the way it is, Im just not happy with it.

!!!!!!!!!

Take that

!!

and that (is he dead yet?)