75 lines
3.7 KiB
Plaintext
75 lines
3.7 KiB
Plaintext
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.
|