5.1.4 Security Concerns

Security problems are, fortunately, rather rare on MUCKs. Most MUCKs function — quite successfully — in a climate of trust, but giving thought to security issues is one of your responsibilities as an administrator. The issues are magnified if you become an administrator on a large MUCK, or if your MUCK attracts a sizeable player base.

In this section, `security' is meant as `protection against unauthorized modification or destruction of the database itself, or of database objects'. This is somewhat different than the related issue of privacy. Privacy issues are discussed in Section 5.2.4.

Access to the MUCK Account:

Being able to log onto the server account the MUCK is run from is the trump card of all security concerns. With access to this account, someone bent on mischief or destruction can do anything: change God's password, alter logs, or destroy the database and all backups. Someone bent on safeguarding the MUCK can undo any damage: no matter what has gone wrong or been destroyed on the MUCK, the world can be restored to sane and healthy condition by restoring from back ups.

So, control over and awareness of who has access to this account is the foremost security concern. If you own the machine the MUCK runs on, and are able and willing to do all site administration tasks, the issue is considerably simplified: don't give anyone else the password to the account.

For most MUCKs, the situation is a bit more murky. Often someone else owns the machine. Sometimes the site administrator is a wizard on the MUCK, but only marginally involved in its day-to-day affairs. Sometimes several staff members end up having access to the account: God has access because it is, after all, her world; the site admin has access because it is, after all, his computer; the player relations and security wiz ends up getting access so he can review logs in situations where one player has charged another with some kind of offense; the wiz responsible for creating new characters gets access so she can check email for char requests; perhaps another wizard is given access so he can update news, info, and help files. (For some things, you can enlist server-side help from staff members without giving them access to the account. For example, a separate account could be set up for the security wiz, and you could copy the log back ups to a directory in that account, rather than game/logs. A separate account can be set up for the wizard who does character creation, with char requests to be mailed there, or mail can be forwarded to her.)

If this is a team of trustworthy people, then things are grand. Work is shared among several people, and any one of them could log on to deal with an emergency, such as restarting the MUCK after a power failure. But, be aware: if you share access to the MUCK account, you no longer have total assurance that the MUCK is safeguarded. It is conceivable that one of these people will get mad at you, or at life, the universe, and everything, and destroy the MUCK, or that one will give the account password to someone you don't know.

Keeping Backups

The server does a certain measure of backup on its own. At restart (assuming you are using the standard database filenames) the database used at the previous restart, std-db.db, is copied to std-db.old, and the most current form of the database (std-db.new, created from the most recent dump) is copied to std-db.db. So, at any given moment, you have three versions of the database on hand.

You may want to take this a step further. Copying the most recent database file to another file and compressing it gives you a safe copy. Depending on your energy level and disk space, you may want to do a rotating swap of database back ups similar to the one suggested for logs.

  mv backup2.gz backup3.gz
  mv backup1.gz backup2.gz
  cp std-db.new backup1
  gzip -9 backup1

The reason for keeping older backups is that it's possible for a database to become corrupt during normal operation: some bug in the server or on-line programs creates inconsistencies in the database file. In this situation, the most recent backup file is not necessarily the best one: it too could be affected.

Also, to safeguard against hardware or access problems, you may want to do an offsite back up. With File Transfer Protocol, this is a simple (but potentially time-consuming) process. FTP your most recent backup to some other host. If your server goes down, or one of your wizards goes bonkers and deletes the backups, you can set up on an alternate site.

Access to #1:

Next in the hierarchy of security issues is access to the God character. If the MUCK is compiled with God privileges, only God can set players W or !W, or change wizards' passwords. Also, only God can use the utilities for analyzing and repairing the database, @sanity and @sanfix.

On most established MUCKs, God is not used as an actual player. The primary wizard of the MUCK will create a wizard character for daily use, and only log onto #1 to only set or unset players' wizbits or to use the database utilities. In part this is for security: just as UNIX sysadmins do their normal work from an account other than root, MUCK Gods do their normal work from a different character. In part it is simply a convenience: wizards sometimes need to force themselves, or use programs that force them, and #1 can't be forced. Also, #1 always gets the full-data WHO screen (which wizards see when typing WHO*), whether she wants it or not. And in part it's a matter of facilitating administration of the MUCK. Sometimes the de facto God of the MUCK (the overall administrator who appoints wizards, determines policy, etc.) and the most technically accomplished staff member (the person who would handle matters such as running @sanfix) are two different people, so both have reason for using #1. Or — a rather common situation — there is no single wizard with total control; rather, leadership is shared among a core group of wizards, each having access to the God character.

Whatever set up you use, the password to #1 is an important piece of information, and should only be given out on a need-to-know basis.

Wizards:

Most wizards are committed to their worlds, and would never directly harm it, but the possibility exists. It's not unheard of for an immature wizard to get angry and destroy a world. The MUCK can recover from this by restoring from back ups, but obviously this is an unpleasant chore.

More common problems come about inadvertently. Most are minor: a wizard with wayward fingers mistypes #321 for #312, and recycles some important room or command. So, you fix it.

Sometimes players @force lock themselves to each other. Wizards shouldn't. When you appoint a new wizard, check his force lock. When he was a player, it was fine for his roommate to be able to force his sleeping body downstairs when she had visitors, but it's not fine for her to be able to force him once he is a wizard.

Wizards should also be aware of a specific line of attack that can be used to modify objects with the wizard's permissions. You can set properties on objects you control (you control everything). Also, objects you control can set properties on other objects you control (and you control everything). And, properties can include MPI that causes programs or other properties to execute. (This is true for players too, but the implications are less threatening.) For wizards, these events are carried out with wizard permissions. In short, and without providing specific recipes, a naughty player can make objects which — if they are owned by a wizard — can do naughty things. Whenever you @chown an object, examine its properties, with particular attention to MPI that stores values or calls properties or programs ({store}, {exec}, {lexec}, {muf}, and the like).

Programs:

Wizard programs can do pretty much anything a wizard can do, and M3 programs are quite powerful as well. As with security issues regarding wizards, the trick is to identify and support trustworty people (and programs), and to be aware of the issues, rather than trying to anticipate and safeguard against every possible threat.

Your best defense against security breaches through programs is to appoint a good MUF wizard. This staff member determines who gets Mucker bits, with special attention to M3's, and reviews global and public programs, with special attention to programs that players ask to port from elsewhere. If you are not particularly MUF savvy, or if you are a good coder but lack the sneaky mindset necessary to be a good hacker or anti-hacker, you should recruit someone with these qualities. (Surprisingly, it is possible to find honest sneaky people.)

Some general points...

The apparent purpose of a program is no guarantee of its potential threat or lack thereof. If someone asks you to port a 2000-line Poker program that needs to be set Wizard so it can keep scores in a protected .scores/ directory, approach it as a wizbitted program large enough to hide some Trojan horse feature, and not as `just a card game'.

*

Programs set Link_OK are public: they can be listed, linked to, and called by other programs. Many are a little too trusting: they assume that you (the person using the program) are who you're supposed to be. And, if you use them in the normal way, you are. But it is a trival matter to concoct a small stub program that stores an incorrect dbref in the `me' variable, puts an argument string on the stack, and then calls a public program. An M2 morphing program may seem perfectly safe — after all, people won't put harmful things in their own descs — but consider: JoeHacker(#666PBJM2) might be able to store #1 or the dbref of some other wizard in `me', put a string holding naughty MPI onto the stack, and then call the morph program, creating a situation where the next time someone looks at the wizard, untoward things will happen.

Fortunately, there is a rather simple way to plug this hole. Check all Link_OK programs; if they don't guard against such assualts, edit them, adding a line that does so. Before the first line of the last function in the program, insert the following line:

  "me" match me !

This explicitly matches the dbref of the triggering player or puppet, and stores it in the `me' variable.

*

In general, any program should be run with with the lowest permissions level that will work. If a program will run at M2, set it M2, not M3 or W. If a program doesn't need to be owned by a wizard, consider chowning it to some mortal, possibly an NPC you use for just this purpose.

*

You owe it to yourself and your players to make your policies on security and privacy concerns as they pertain to programming explicit. Providing a document stating this policy, readable through the `news' or `info' command, is a very good idea. A sample policy is provided in Appendix B. The sample policy may be freely copied and edited to meet your MUCK's needs.