<!-- MHonArc v2.4.4 -->
<!--X-Subject: Re: System Security (was: Re: [MUD-Dev] players who "take away from the game") -->
<!--X-From-R13: Qlaor eh Fnera <plaorNzhd.bet> -->
<!--X-Date: Thu, 11 Nov 1999 15:05:57 -0800 -->
<!--X-Message-Id: 199911112301.RAA28137#laurel,actlab.utexas.edu -->
<!--X-Content-Type: text/plain -->
<!--X-Head-End-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<html>
<head>
<title>MUD-Dev message, Re: System Security (was: Re: [MUD-Dev] players who "take away</title>
<!-- meta name="robots" content="noindex,nofollow" -->
<link rev="made" href="mailto:cynbe#muq,org">
</head>
<body background="/backgrounds/paperback.gif" bgcolor="#ffffff"
text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000">
<font size="+4" color="#804040">
<strong><em>MUD-Dev<br>mailing list archive</em></strong>
</font>
<br>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
<br clear=all><hr>
<!--X-Body-Begin-->
<!--X-User-Header-->
<!--X-User-Header-End-->
<!--X-TopPNI-->
Date:
[ <a href="msg00220.html">Previous</a>
| <a href="msg00221.html">Next</a>
]
Thread:
[ <a href="msg00217.html">Previous</a>
| <a href="msg00204.html">Next</a>
]
Index:
[ <A HREF="author.html#00222">Author</A>
| <A HREF="#00222">Date</A>
| <A HREF="thread.html#00222">Thread</A>
]
<!--X-TopPNI-End-->
<!--X-MsgBody-->
<!--X-Subject-Header-Begin-->
<H1>Re: System Security (was: Re: [MUD-Dev] players who "take away from the game")</H1>
<HR>
<!--X-Subject-Header-End-->
<!--X-Head-of-Message-->
<UL>
<LI><em>To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Subject</em>: Re: System Security (was: Re: [MUD-Dev] players who "take away from the game") </LI>
<LI><em>From</em>: Cynbe ru Taren <<A HREF="mailto:cynbe#muq,org">cynbe#muq,org</A>></LI>
<LI><em>Date</em>: Thu, 11 Nov 1999 17:01:39 -0600</LI>
<LI><em>Reply-To</em>: <A HREF="mailto:mud-dev#kanga,nu">mud-dev#kanga,nu</A></LI>
<LI><em>Sender</em>: <A HREF="mailto:mud-dev-admin#kanga,nu">mud-dev-admin#kanga,nu</A></LI>
</UL>
<!--X-Head-of-Message-End-->
<!--X-Head-Body-Sep-Begin-->
<HR>
<!--X-Head-Body-Sep-End-->
<!--X-Body-of-Message-->
<PRE>
On Wed, 10 Nov 1999 22:00:11 -0700
cg <cg#ami-cg,GraySage.Edmonton.AB.CA> wrote:
> [Eli Stevens:]
>> This got me wondering... :)
>>
>> What precautions should be taken when writing a MUD codebase from
>> scratch? Are most security holes that a MUD box might have at
>> the OS level, or does having a program like a MUD running open up
>> opportunities that would not otherwise exist (assuming that the
>> ability to issue OS commands and such is not a feature)?
Issues I would (well, have :) look at:
* Obviously, but apparently not obviously enough (since they keey
hitting the news): Buffer overflow bugs.
You want to design all your I/O buffer handling, text/string
manipulation &tc so that these are -structurally- almost impossible,
instead of depending on line-by-line individual feature coding to
do everything right in spite of the basic architecture.
E.g., using C++ style string classes instead of by-hand malloc()/free()
logic can make it a lot less likely some string operation somewhere in
midnight madness feepland is subject to buffer overflow.
* Next to specific buffer over-runs, array indexing errors and
pointer arithmetic are likely the most fruitful source of exploitable
bugs.
If security matters, you may want to pick an implementation
language or coding style which inherently minimizes the potential
for these: Avoid pointer arithmetic and use C++ array classes
written to do bounds checking, say. The added peace of mind
can easily justify the extra runtime overhead.
Many such bugs are ultimately caused by having to do manual
storage allocation at a micro-level and screwing up. You may
wish to architecturally eliminate this class of bugs either
by adopting static allocation (if your design is simple enough
to allow it at acceptable cost in space), or else by supplying
a system-wide automatic storage allocation mechanism, either
an off-the-shelf refcounter or garbage collector or perhaps
something custom, depending on the design.
* Try to architecturally make the security kernel -- the subset of the
program which -must- be correct for security to be maintained -- as
small and stable as possible.
The first stage here, obviously, is to -have- a security kernel, as
opposed to having the security of the system depend on basically
every line of code in it. :)
The second stage is to make the functionality of that kernel as
efficient, general-purpose and policy-free as possible: This
minimizes the need/temptation to go mangling it and introducing
new security holes.
An application language powerful and efficient enough that most
feepage can be done safely in it rather than dangerously in the
underlying C server can add a lot to long-term security.
* Segregate all host-OS access out carefully, grant such access
extremely sparingly, and scrutinize the resulting code with
imagination and rampant paranoia.
E.g., are you logging outside-triggered events to a host
file?
Sounds simple and safe, but deliberately flooding the
server with such events may cause the logfile to fill a critical
partition: Will all affected processes remain secure in that case?
You may need to check all diskwrites to see what happens upon
disk-full errors, and think about it.
You can put a limit on how long the logfile is allowed to get --
but now you've provided an attacker with a ready-made way of
covering tracks, by just scrolling the critical episode off
the log via lots of noise events afterwards.
The typical security hole seems to trace back to some little
convenience feep done with the mind on things other than security: The
server design goal is to make the system secure even in the face of
utter idiocy on the part of someone doing such little feeps in a hurry
on caffiene at 5:57AM before running to catch the bus.
The above all relates to just keeping the host OS account(s) secure
from folks using the server: Keeping the internal contents of the
server sane in the face of in-server meddling is a complete extra
security front calling for some up-front model of how privileges are
handed out and enforced.
It is hard to say much general about that except that if you start
with no clear security design, you'll wind up with effectively no
security at this level -- pretty much the standard state of affairs.
Multi-user OSes, capability designs, file access control lists &tc can
provide some models on which to base your internal security mechanisms
at this level, if you wish to take the problem seriously.
It is much easier, of course, to shrug, provide nothing, and blame the
application programmer any time some simple coding slip brings the
whole house of cards down.
:)
My $0.02 worth.
Cynbe
_______________________________________________
MUD-Dev maillist - MUD-Dev#kanga,nu
<A HREF="http://www.kanga.nu/lists/listinfo/mud-dev">http://www.kanga.nu/lists/listinfo/mud-dev</A>
</PRE>
<!--X-Body-of-Message-End-->
<!--X-MsgBody-End-->
<!--X-Follow-Ups-->
<HR>
<!--X-Follow-Ups-End-->
<!--X-References-->
<!--X-References-End-->
<!--X-BotPNI-->
<UL>
<LI>Prev by Date:
<STRONG><A HREF="msg00220.html">Re: [MUD-Dev] players who "take away from the game"</A></STRONG>
</LI>
<LI>Next by Date:
<STRONG><A HREF="msg00221.html">bugs (was RE: [MUD-Dev] players who "take away from the game")</A></STRONG>
</LI>
<LI>Prev by thread:
<STRONG><A HREF="msg00217.html">Re: System Security (was: Re: [MUD-Dev] players who "take away from the game")</A></STRONG>
</LI>
<LI>Next by thread:
<STRONG><A HREF="msg00204.html">[MUD-Dev] MySQL as a MUD.</A></STRONG>
</LI>
<LI>Index(es):
<UL>
<LI><A HREF="index.html#00222"><STRONG>Date</STRONG></A></LI>
<LI><A HREF="thread.html#00222"><STRONG>Thread</STRONG></A></LI>
</UL>
</LI>
</UL>
<!--X-BotPNI-End-->
<!--X-User-Footer-->
<!--X-User-Footer-End-->
<ul><li>Thread context:
<BLOCKQUOTE><UL>
<LI><STRONG>Re: [MUD-Dev] Neverwinter Nights</STRONG>, <EM>(continued)</EM>
<ul compact>
<LI><strong><A NAME="00211" HREF="msg00211.html">Re: [MUD-Dev] Neverwinter Nights</A></strong>,
Dundee <a href="mailto:SkeptAck#antisocial,com">SkeptAck#antisocial,com</a>, Thu 11 Nov 1999, 19:02 GMT
</LI>
</ul>
</LI>
<LI><strong><A NAME="00206" HREF="msg00206.html">Re: System Security (was: Re: [MUD-Dev] players who "take away from the game")</A></strong>,
cg <a href="mailto:cg#ami-cg,GraySage.Edmonton.AB.CA">cg#ami-cg,GraySage.Edmonton.AB.CA</a>, Thu 11 Nov 1999, 18:43 GMT
<UL>
<LI><strong><A NAME="00215" HREF="msg00215.html">Re: System Security (was: Re: [MUD-Dev] players who "take away from the game")</A></strong>,
J C Lawrence <a href="mailto:claw#cp,net">claw#cp,net</a>, Thu 11 Nov 1999, 22:01 GMT
</LI>
</UL>
<UL>
<li><Possible follow-up(s)><br>
<LI><strong><A NAME="00217" HREF="msg00217.html">Re: System Security (was: Re: [MUD-Dev] players who "take away from the game")</A></strong>,
Bruce Mitchener, Jr. <a href="mailto:bruce#puremagic,com">bruce#puremagic,com</a>, Thu 11 Nov 1999, 22:33 GMT
</LI>
<LI><strong><A NAME="00222" HREF="msg00222.html">Re: System Security (was: Re: [MUD-Dev] players who "take away from the game")</A></strong>,
Cynbe ru Taren <a href="mailto:cynbe#muq,org">cynbe#muq,org</a>, Thu 11 Nov 1999, 23:05 GMT
</LI>
</UL>
</LI>
<LI><strong><A NAME="00204" HREF="msg00204.html">[MUD-Dev] MySQL as a MUD.</A></strong>,
Quzah <a href="mailto:quzah#hotmail,com">quzah#hotmail,com</a>, Thu 11 Nov 1999, 18:43 GMT
<UL>
<LI><strong><A NAME="00210" HREF="msg00210.html">Re: [MUD-Dev] MySQL as a MUD.</A></strong>,
Holly Sommer <a href="mailto:hsommer#micro,ti.com">hsommer#micro,ti.com</a>, Thu 11 Nov 1999, 19:02 GMT
<UL>
<LI><strong><A NAME="00224" HREF="msg00224.html">Re: [MUD-Dev] MySQL as a MUD.</A></strong>,
J C Lawrence <a href="mailto:claw#cp,net">claw#cp,net</a>, Thu 11 Nov 1999, 23:20 GMT
</LI>
<LI><strong><A NAME="00226" HREF="msg00226.html">RE: [MUD-Dev] MySQL as a MUD.</A></strong>,
Ian Macintosh <a href="mailto:iman#issystems,co.nz">iman#issystems,co.nz</a>, Fri 12 Nov 1999, 01:10 GMT
</LI>
</UL>
</LI>
</UL>
</LI>
</UL></BLOCKQUOTE>
</ul>
<hr>
<center>
[ <a href="../">Other Periods</a>
| <a href="../../">Other mailing lists</a>
| <a href="/search.php3">Search</a>
]
</center>
<hr>
</body>
</html>