Propval: Propval-based authentication is the most
flexible scheme: scope administrators may use the +security
#propvals command to go to a prompt session and specify
prop:value pairs that give varying levels of access. They may specify
either properties holding a specific value, or properties that hold
any true value. When a player attempts to use a configured lock within
the scope, the system checks all his or her property values, and
calculates his or her highest level of access. He or she will be able
to use the exit if its security level is equal to or lower than the
player's calculated level of access.
====================================
>> Does this security system support remote monitoring? (y/n)
====================================
Answering `yes' to this prompt indicates that the system supports
remote monitoring: scope admins may use the +security
#monitor command to configure exits or rooms to be monitored. Any
activity in a monitored room is relayed to configured control rooms.
When any player uses a monitored exit, a notice is emitted in control
rooms. If an attempt to bypass or subvert the system results in a
critical failure, a alarm is emitted in all control rooms.
====================================
>> Does this security system support centralized control rooms? (y/n)
====================================
Answering `yes' to this prompt indicates that the system supports
centralized control. This allows monitoring capabilities, and also makes
the system more secure in that any player access level changes may only
be made in designated control rooms. This includes attempts to make
unauthorized changes to one's own access level by subverting the
system.
====================================
>> Does this security system support multilocks? (y/n)
====================================
Answering `yes' to this prompt indicates that the system supports
multilocks: level 5 exits or commands that require the input of two or
more players with level 5 clearance. Its intended use is for things like
a self-destruct command built into a space ship: in order to activate
the ship's self-destruct system, two (or more) players with level 5
clearance would have to issue the command.
====================================
>> Are any abilities required to install this system? (y/n)
>> NOTE: These are simply abilities the character has to have.
>> No rolls will be made against abilities specified here.
>> What is the category of this ability?
>> [Enter category ('stats', 'skills', etc), .n for none, or .q to quit]
>> What is the instance of this ability?
>> [Enter instance ('str', 'mechanic', etc), or .q to quit]
>> What is the level of this ability?
>> [Enter level number, or .q to quit]
>> Ability entered.
>> Are any other abilities required? (y/n)
====================================
For non-staff players, abilities may be required in order to install
the systems. (Staff members may install security systems with automatic
success.) As with other ability specifications when defining database
entries, you do so by specifying the category of the ability, then the
specific instance of the ability within that category, then the required
ability level. For example, to specify that players must have the
Security Systems skill at level 2 in order to install a system, you
would enter 'skill', 'security systems', and '2', respectively, at these
prompts.
====================================
>> Is one or more rolls required to successfully install this system? (y/n)
>> NOTE: More than one roll may be specified. If multiple rolls are
specified, the player must succeed on all rolls in order to
successfully install the system.
>> What is the category of this ability?
>> [Enter category ('stats', 'skills', etc), .n for none, or .q to quit]
>> What is the instance of this ability?
>> [Enter instance ('str', 'mechanic', etc), or .q to quit]
>> What is the difficulty modifier for this roll?
>> [Enter difficulty modifier, or .q to quit]
>> Roll entered.
====================================
If you specify that players must have certain abilities in order to
install a security system, you may also specify whether they must make
ability rolls in order to successfully do so. The ability to be rolled
against is specified in the standard format. You are then prompted for a
difficulty modifier: for an especially sophisticated and difficult
system, use a negative modifier. For a straightforward system, use a
positive modifier. Or, use a modifier of zero if the system is neither
especially hard or especially easy to install. This modifier will be
added to the number the player must roll below in order to successfully
install the system. If a player's attempt to install a system fails, the
system will become broken. That is, they will not be able to install it
until it is repaired. Security systems, like other objects, are repaired
with the +repair command.
====================================
>> Are any tools required to install this system? (y/n)
>> What tools are required to install the system?
>> [Enter *class* of tool, or .q to quit]
>> How many instances of this tool are required?
>> [Enter a number, or .q to quit]
>> Tool entered. Are any other tools required? (y/n)
>> What tools are required to install the system?
>> [Enter *class* of tool, or .q to quit]
>> How many instances of this tool are required?
>> [Enter a number, or .q to quit]
>> Tool entered. Are any other tools required? (y/n)
>> Are any materials required to install this system? (y/n)
====================================
As with other types of object definitions, you may specify tools
and materials required to install the system. Tools may be used multiple
times; materials are used up in the process of installation. The
automatic installation process used for staff members does not check for
tools or materials, and does not use up materials.
====================================
>> What is the tech level of this system?
>> [Enter tech level, or .d for realm default, or .q to quit]
====================================
The security system is one of the few aspects of Argo that
makes coded use of tech levels: The difference between a player's tech
level and that of a security system he or she is trying to bypass or
subvert is applied as a roll modifier. Players will have more difficulty
hacking a security system that is based on technology that is more
sophisiticated than what they have grown up with.
====================================
>> What is the security rating of this system?
>> [Enter security rating, or .q to quit]
====================================
The security rating of a system is a raw, arbitrary representation of
its strength. The security rating is applied as a die modifier to each
roll to bypass or subvert the system. Systems with higher security
ratings are harder to bypass or subvert. For high tech systems, a high
security rating would reflect sophisticated programming and hardened
construction and redundant systems. For a low tech security system, such
as passwords, it would reflect things such as the overall loyalty of
guards and/or the severity of punishments meted out to traitors.
====================================
>> Can any Argo abilities be used to bypass this system? (y/n)
>> You may specify multiple abilities. If multiple abilities are
specified, the player must have all of them to bypass security.
>> What is the category of this ability?
>> [Enter category ('stats', 'skills', etc), .n for none, or .q to quit]
>> What is the instance of this ability?
>> [Enter instance ('str', 'mechanic', etc), or .q to quit]
>> What is the level of this ability?
>> [Enter level number, or .q to quit]
>> Ability entered.
>> Are any other abilities required? (y/n)
====================================
In the context of Argo security systems, 'to bypass' means
to use IC skills to get past exits that are locked against you by the
system... Lockpicking, bribery, computer hacking skills... any of these
are reasonable candidates for bypass skills. If multiple abilities are
specified, the player must have all abilities and a roll will be made
for each one.
Critical failure when attempting to bypass will sound alarms in any
monitor locations for the security scope. If players do not want to
attempt to bypass when they encounter exits locked against them, they
should use the '+security #nobypass' command, which will set a
preference indicating that the bypass should not be attempted. They can
reenable bypass attempts by typing '+security #bypass'.
====================================
>> Are any tools required to bypass this system? (y/n)
>> What tools are required to bypass the system?
>> [Enter *class* of tool, or .q to quit]
>> How many instances of this tool are required?
>> [Enter a number, or .q to quit]
>> Tool entered. Are any other tools required? (y/n)
====================================
Bypassing the system may require specialized tools, such as
lockpicks.
====================================
>> Can any Argo abilities be used to subvert or crack this system? (y/n)
>> You may specify multiple abilities. If multiple abilities are
specified, the player must have all of them to subvert the system.
>> What is the category of this ability?
>> [Enter category ('stats', 'skills', etc), .n for none, or .q to quit]
>> What is the instance of this ability?
>> [Enter instance ('str', 'mechanic', etc), or .q to quit]
>> What is the level of this ability?
>> [Enter level number, or .q to quit]
>> Ability entered.
>> Are any tools required to subvert this system? (y/n)
>> What tools are required to subvert the system?
====================================
In the same manner, you may specify abilities and tools needed to
subvert the system. A player who successfully subverts a security system
gain administrative access: he or she may change other player's access
levels, reset locks and passwords, etc. As with bypass atempts,
critical failures rolled when attempting to subvert a security system
will sound alarms in any monitor rooms. To attempt to subvert a system,
a player types '+security #crack' somewhere within the security scope.
If the security scope is configured with control rooms, the player must
be within a control room in order to attempt to subvert the system.
====================================
>> Are any abilities required in order to analyze the system and detect
>> system violations, or to repair a broken system? (y/n)
>> You may specify multiple abilities. If multiple abilities are
specified, the player must have all of them to analyze the system.
>> What is the category of this ability?
>> [Enter category ('stats', 'skills', etc), .n for none, or .q to quit]
>> What is the instance of this ability?
>> [Enter instance ('str', 'mechanic', etc), or .q to quit]
>> What is the level of this ability?
>> [Enter level number, or .q to quit]
>> Ability entered.
>> Are any other abilities required? (y/n)
>> Are any tools required to analyze or repair this system? (y/n)
====================================
Players with the required abilities and tools may analyze the system,
looking for security breaches. On a sucessful roll, they will find out
whether or not the system has been compromised. With a critical success,
they will find out by whom the system has been compromised, if anyone.
If the player analyzing the system rolls a critical failure, he won't
learn of intrusions, and the system will be weakened... that is, its
security rating will go down by one.
====================================
>> What is the standard price of this system?
>> [Enter price in credits, or .q to quit]
>> System defined.
====================================
Finally, enter the price of the system, in small coins.
Using Security Systems
For players, the security system is largely transparent. If the
system uses keys or keycards, they only need to have their key or card
with them in order to use exits they are authorized for. To use exits
within a scope controlled by a passwords, they should type '+security
#password <password>' to enter their password. From this point on,
they can use any exits that their password gives sufficient clearance
for. For auto and group-based systems, players don't need to take any
steps: they will be able to use authorized exits, and will not be able
to use unauthorized exits. If players don't have bypass abilities,
and/or don't want to inadvertently trip security monitors, they should
do '+security #nobypass'. To attempt bypasses, they should do '+security
#bypass.'
Administrators of a security scope will need to be familiar with a
few additional commands:
+sec #analyze ................ Attempt to detect system violations
+sec #initialize ............. Reinitialize scope key value*
+sec #level <obj>=<level> .... Set <obj>'s security level to level*
+sec #key <level> ............ Create a <level>-level key*
+sec #card <player> .......... Create a security card for <player>*
+sec #max .................... Go to maximum security (All 5)*
+sec #nomax .................. Stand down from maximum security*
+sec #monitor [<rm|exit>] .... Toggle objects's monitoring status*
+sec #monitor <obj>=<fmr> .... Format <obj>'s monitor display name*"
+sec #control ................ Toggle room's control-room status*
+sec #include <exit> ......... Include exit in security system*
+sec #exclude <exit> ......... Exclude exit from security system*
+sec #multiple <exit>=<num> .. Configure exit to require <num> users*
+sec #newpassword ............ Configure password authentication*
+sec #groups ................. Configure group authentication*
+sec #propvals ............... Configure propval authentication*
+sec #admins ................. Configure scope admin list*
+sec #setup .................. Set up a new scope
+sec #remove ................. Remove current scope*
To install a security system, take the security system object to an
environment room containing the area to be controlled by the system, and
type '+security #setup'. If the setup is successful, a
prompt will ask if you want to set default security levels on
room-to-room exits within the scope, and if so, what the default
security level is to be.
After the system is installed, you can include new exits (either
room-to-room, or command actions) with the #include option,
and use the #level option to set the exit's required
security level. Configured exits can be removed from control by the
security system with the #exclude option.
To designate other players as scope admins, type '+security
#admins', and follow prompts.
The way you will give players levels of access will differ depending
on the system's authentication method. For password systems, simply tell
them the current password for the level of access you want them to have.
For key-based systems, create a key that gives access for the security
level you want them to have, and give them the key. For keycard-based
systems, type '+security #level
<player>=<level>' to set a player's security level,
then '+security #card <player>' to create a card for
them. Then give the player the card. For auto systems, just do
'+security #level <player>'.
The #initialize option provides a way to 'change the
locks', as it were, on key- and keycard-based systems. If you
reinitialize the scope with this option, outstanding, previously created
keys and cards will no longer work... people will need to be reissued
new keys or cards.
Security systems may be defined as supporting control rooms and
monitoring. Control rooms are a way of limiting administrative access to
the system: if one or more control rooms are set up, players must be in
a control room to make administrative settings to the system; if there
are no control rooms, settings can be made anywhere in the scope.
Control rooms are also the broadcast point for remote monitoring: if the
system supports both control rooms and remote monitoring, activity in
monitored rooms will be broadcast to control rooms. Use the
#control option to toggle a room's control room status. Use
the #monitor option to toggle whether or not a room is being
monitored.
A group-based system can be reconfigured (that is, permission levels
can be assigned to or revoked from groups) by typing '+security
#group', and following prompts. A password-based system can be
reconfigured by typing '+security #newpassword'. A
propval-based system can be reconfigured by typing '+security
#propvals'.
The #max option provides a way to go to maximum security
with a single command. When it is executed, all configured exits in a
scope immediately go to security level 5. You must be a scope admin to
go to maximum security. If your scope has configured control rooms, you
must also be in a control room. To stand down from maximum security
(that is, to return exits to their standard security level), use the
#nomax option.
You can completely remove the security system by typing
'+security #remove', and enterying 'yes' at the
confirmation prompt.
prev |
toc |
top