		 Nightmare 3.3/Foundation I Security
		     Created by Descartes of Borg

Nightmare 3.3 has moved to a new style of security called stack
security.  Stack security differs completely from the old EUID/UID
method.  This document attempts to detail stack security.

Stack security relies on checking an entire call stack for security
operations.  With the old style security, the master object would only
check the to see if the object asking for access had access to perform
a certain operation.  For example, say object A wanted to write to a
file.  No matter how it got to desire to write to that file, the
master object would allow or deny it access based solely on its
merits.  A good way, therefore, to defeat the old security system
would be to fake out object A and get it to write to a file using its
priveledges for you.

With stack security, an object cannot be used to fake out the master
object.  Instead, the master object traverse the entire call stack to
be certain that it should allow access.  Take a rm command.

I issue the command rm.  The player object calls the command daemon.
The player object then calls the rm command.  The rm command tries to
rm the file.  So you have 3 objects here on the stack, my player
object two times, and the rm command (the command daemon made no
external calls, so it is not on the stack).  In order for the rm
command to succeed, I and the rm command must all have access to rm
the file.  As an admin, I have the access, and the rm command as well
has that access, so the command succeeds.  If it had been a regular
creator however, perhaps trying to rm the master object, the operation
would have failed.  The rm command still would have had access, but
the creator's player object would not have.

In order to understand how this works, you must understand the
difference between file protection and object access.  File protection
is the level of protection a file has from operations of other
objects.  File protections are defined in /secure/cfg/read.cfg and
/secure/cfg/write.cfg.  File protections must ALWAYS be greater than
or equal to the access an object cloned from that file has.  If not,
then you have a security leak.

File access is defined through the SimulEfun file_privs().  Upon
creation, each object gets a privs string which is a list of privs
separated by a :.  Player objects always have their name as part of
their privs string.  Privs can never change once set.

By making protection greater than access, what I mean is this:
Any object which has access to a given file should on its own have
access to any files which an object created from that file would have
access to.  For example, /secure has access to everything.  Therefore,
only SECURE objects should have access to it.  If you allow any priv,
say an admin priv like descartes, to have access to /secure, you are
by default giving SECURE access to that outside priv.  So now anything
which can write to my home directory can become SECURE!

The final key to the stack security system is the unguarded()
SimulEfun.

mixed unguarded(function f);

Any object can make an old-style, depend on me only operation by
making that function unguarded.  For example, I am a creator that has
a guild object which needs to save to my home directory.  My guild
object has write access to my home directory, but players using it
would not.  So stack security would make it impossible for you to have
any such object.  If, in the guild object, you have the following
call:

unguarded((: save_object, "/realms/descartes/guild/save/obj" :));

The object will saved based SOLELY on the permissions which the guild
object has.  If the guild object can write to the directory, then the
operation succeeds regardless of the rest of the stack.  If the guild
object can't do it, then the operation fails.
