The system commands described on the following pages can create, manipulate, or restrict files that can affect system security. Because of the nature of these commands, it is advisable to restrict their use to trusted individuals.
Restriction can take two forms:
-
Defining no SYSTEMUSERs in the USERDATAFILE, and restricting physical access to all ODTs, remote ODTs, and super-user stations. Any remote ODTs and super-user stations must be kept physically secure against unauthorized use.
-
Authorizing security-administrator status on the system (setting the value of the system SECADMIN option to TRUE). Only a user with SECADMIN designated for his or her usercode can use the following commands.
MP (Mark Program) Command
The MP (Mark Program) command enables you to display or change any of several options of object code files. Several of these options grant special privileges to any processes that result from initiating that object code file.
In some cases, a single process can execute procedures from multiple object code files. This is the case if the process invokes a library procedure, or if a program receives a procedure parameter from its initiator. A process can temporarily gain or lose privileges when it enters a procedure stored in a different object code file. The object code file privileges that apply to a process at a given time are those associated with the procedure most recently entered, and not yet exited, by the process.
Assigning Compiler Code File Status
An object code file can be marked as a compiler code file by the MP <file title> + COMPILER form of the MP command.
A file marked as a compiler code file can generate or write to code files. A compiler has the potential to make nonprivileged programs privileged and, in more fundamental ways, disrupt system security checks. Applying compiler code file status to an object code file that is TADS-capable might result in opening parts of system memory to unauthorized examination. A TADS-capable file is the result of a successful compilation with the TADS (Test and Debug System) option specified.
If the file is TADS-capable and the system is running with the system security option TADSWARN set, a warning message results when you mark the object code file as a compiler code file.
Assigning Privileges and Tasking Status
The following are some related options of the MP command, and explanations of the types of privileges they confer.
|
Option |
Privileges |
|---|---|
|
KERBEROS |
This option enables the security administrator to mark a program as having the privilege to create, access, and update disk files whose Boolean file attribute KERBEROSACCESS is set to TRUE. MP KERBEROS gives the Kerberos library the privilege necessary to open and read the Kerberos Key Table file. This file contains security-sensitive data such that only code from the Kerberos library can read from or write to it. The MP KERBEROS command is used by the system software generation process. Normally, sites should not have to use this command. |
|
PU |
This option confers privileged status. The program receives privileges similar to those conferred on a usercode that has the PU usercode attribute set, as described under “Unrestricted File Access (PU)” in Controlling System Access. A process receives privileged status if PU is set either for the usercode of the process or the object code file. |
|
SECADMIN |
This option confers security-administrator status. The program receives privileges similar to those conferred on a usercode that has the SECADMIN usercode attribute set, as described under “Security Function Access (SECADMIN)” in Controlling System Access. A process receives security-administrator status if SECADMIN is set either for the usercode of the process or for the object code file. |
|
SYSADMIN |
This option confers system-administrator status. A program with SYSADMIN privilege has the same privileges as a program running under a usercode with SYSADMIN privilege. |
|
TASKING |
This option confers tasking status. The program receives privileges similar in most respects to those that the system grants to a message control system (MCS). These privileges include those associated with PU privileged status, as well as the ability to use several forms of the USERDATA function, to survive various normally fatal errors, and to access protected system libraries. For details about MCS and tasking privileges, see the Task Management Programming Guide. When an MP command confers tasking status to a program that runs under a usercode, that program retains the privileges of that usercode until the program exercises its tasking privilege to nullify the usercode by setting it to a period (“.”). |
For each of these options, the MP command allows you to enable the option, disable the option, or make the option transparent.
For example, the following MP command marks the program OBJECT/OMEGA with privileged status and security administrator transparent status, and deletes tasking status:
MP OBJECT/OMEGA + PU, + SECADMIN TRANSPARENT, - TASKING
If you enable any of these options, and the object code file is TADS-capable, and the system is running with the system security option TADSWARN set, then the system displays a warning message.
In the case of shared libraries, you might choose to ensure that exported procedures inherit the privileges of the user programs that enter them. To do so, set the various privilege options to their transparent state: privileged transparent, security administrator transparent, or tasking transparent. This action causes the procedure to inherit the specified types of privileges from the user program. For example, if a privileged user program enters a procedure in a privileged transparent library program, the procedure is executed with privileged status.
Privileged status, security-administrator status, and tasking status can be inherited through procedures that are transparent to these types of status. However, the inheritance takes place only if each procedure is entered. If the procedure is initiated, it runs without the specified type of privilege. The difference between entry and initiation is that initiation statements create a new process. Examples of process initiation statements are CALL, PROCESS, and RUN.
Transparent privilege is not used when determining “declarer” file access rights. The declarer access rights are based only on the code file in which the file was declared.
Consider the following points when using the PU, SECADMIN, or TASKING option:
-
To avoid the possibility of a nonprivileged user gaining privileged status by executing a library code file that is privileged, make all support libraries privileged transparent.
-
A program that is intended to be marked privileged must not enable nonprivileged users to use the program to circumvent system security. Control access to a program that is to be marked as privileged and is intended for use by nonprivileged users by creating a guard file that specifies the usercodes permitted to execute the program. Do not include any statements that would cause a task file to be opened before a program dump takes place.
-
If a user knows the internal file name of a file in a privileged program, that user can file-equate, and alter the values of the file attributes, including the SECURITYTYPE, SECURITYUSE, and SECURITYGUARD attributes.
-
Assigning privileged program status to a TADS-capable code file might result in opening parts of system memory to unauthorized examination. It is advisable, therefore, to avoid applying the MP command with any of the options PU, SECADMIN, or TASKING to TADS-capable code.
Assigning Executable Status
You can use the EXECUTABLE option of the MP command to mark unsafe object code files as executable. An unsafe object code file is one written in DMALGOL or NEWP that uses unsafe constructs. Examples of unsafe constructs are the DISALLOW statement in DMALGOL, and EXCEPTION procedure declarations with the PROTECTED clause in DMALGOL and NEWP.
The system does not allow any unsafe NEWP object code file to be executed until it has been specifically marked as executable through the MP EXECUTABLE, or SL (Support Library) command. If the system is running with the system security option DMALGOLUNSAFE set to NOTOK, the system also enforces this restriction for unsafe DMALGOL object code files.
Before making a nonexecutable program executable, take appropriate steps, such as making the file private or attaching a suitable guard file, to enable only trusted users or processes to execute the file. Control the use of previously nonexecutable programs that have been made executable.
RESTRICT (Set Restrictions) Command
The RESTRICT (Set Restrictions) system command enables you to place restrictions on access to potentially hazardous files. System files, compilers, backup files, and code files are considered potentially hazardous files.
Suppose an employee who has been working for your organization for only a week brings in a tape he says contains public-domain code files and data that he thinks would be useful to him in his new job. While it is acceptable to permit the data files to be copied to the system, any code file should be trusted only as far as the person vouching for the code file is trusted.
In this hypothetical situation, you could mount the imported tape on a restricted tape drive. Any data file would be treated normally, but system files, compilers, backup files, and code files would be marked as restricted.
The RESTRICT command also enables you to place restrictions on the export of program dump files. (A program dump file is a file created when a program dump is directed to disk.) Such access restrictions enable you to control the use of these files.
If the security option PROGDUMPFILTER is set, you can use the RESTRICT command to prevent a nonprivileged user from exporting a program dump file. See the PROGDUMPFILTER option in SECOPT Option Purposes for more information.
The RESTRICT command has the following syntax:
┌◄───────────── , ────────────┐
── RESTRICT ─┬─────┬─┬─┴─┬─ MT ─┬─<unit number list>─┴────────────┬────┤
└─ - ─┘ │ ├─ PK ─┤ │
│ ├─ DK ─┤ │
│ └─ CD ─┘ │
├─ COMMAND ─┬────────────────────────────────┤
│ │ ┌◄──────────── , ────────────┐ │
│ └─┴─┬───────────┬─┬──────────┬─┴─┤
│ └─<command>─┘ └─<option>─┘ │
├─ VOLUME ──<serial number list>─────────────┤
├─ FILE ──<file list>────────────────────────┤
└─ SC ──<unit number list>─┬─────────────────┤
└─<security info>─┘The RESTRICT COMMAND form of the RESTRICT command can be used to place further security restrictions on the use of system commands. A command that has been restricted can be used only by a user or a program with security administrator privileges.
When security-administrator status has been authorized, restricted commands can be entered from a MARC session that is logged on under a usercode with SECADMIN status, or through the DCKEYIN and SETSTATUS functions if the program has security-administrator status and has the privilege necessary to invoke the function.
A program has security-administrator status if the program is running under a usercode with SECADMIN status or if the program has been given SECADMIN status through the MP (Mark Program) system command. Refer to Setting the System SECADMIN Option (??SECAD Command) for more information.
The commands that can be restricted are primarily those associated with the software configuration of the system, such as the following:
-
DQ (Default Queue)
-
DR (Date Reset)
-
MQ (Make or Modify Queue)
-
OP (Options)
-
SBP (System Balancing Parameters)
-
SF (Set Factor)
-
TR (Time Reset)
Using the RESTRICT COMMAND form, you can restrict a command in combination with any specified option normally available with the specified command. For example, the command RESTRICT COMMAND SYSOPS LANGUAGE restricts only the use of the LANGUAGE option of the SYSOPS command, but has no effect on the other available SYSOPS command options.
When <command> is IK for the RESTRICT COMMAND system command, the possible values of <option> are ADD, DELETE, MERGE, DSAADD, DSADELETE, DSAMERGE, and DSASHOW. The DSAADD option cannot be used with the IK system command.
-
If an option is not specified with RESTRICT COMMAND IK, then all of the listed options for IK require security-administrator status to use.
-
If one or more options are specified with RESTRICT COMMAND IK, then security-administrator status is required for the specified options only.
Programmatic interfaces are available to interface to the keys files. These programmatic interfaces are intended for internal use and consequently are not documented. The restrictions listed for the IK command also apply to the programmatic interfaces. The DSAADD and DSASHOW options can be used to apply restrictions to the interfaces that allow a DSA key to be added and for complete details of DSA keys to be interrogated.
A restricted file other than a backup file can be copied only by a user with privileged status or security-administrator status. A nonprivileged user can copy a restricted backup file. A restricted code file cannot be executed.
When a restricted printer backup file is printed, or a restricted punch backup file is punched, the print subsystem will not use the control block information from the backup file.
A file is marked as restricted in any of the following ways:
-
By being directly designated as restricted (RESTRICT FILE <file title>)
-
By residing on a disk pack that is designated as restricted (RESTRICT DK or RESTRICT PK)
-
By being copied from a tape that is mounted on a tape drive unit that is designated as restricted (RESTRICT MT)
-
By residing on a tape volume that is designated as restricted (RESTRICT VOLUME)
-
By being copied from a foreign host that is marked as restricted (security option HOSTSRESTRICTED specified by SECOPT system command)
To assign log-on restrictions to an ODT, use the RESTRICT SC form of the command.
To remove the security restrictions from a command, specify RESTRICT – COMMAND <command> <option>.
To remove restrictions from a restricted file, pack, tape drive, tape volume, CD, or ODT, use the RESTRICT -- form of the command.
RESTRICT SC: Requiring ODT Log-on
The RESTRICT SC <unit number> form of the command is used to require log-on at a specified ODT, which imposes the same system access checks on the ODT user that are imposed on the user of a remote terminal. In many cases, this restriction means that the would-be user of an ODT must enter a recognized usercode and password before he or she can interact with the system.
Before a user can log on to a restricted ODT, the ODT must be designated as a MARC station. Use the system primitive command ??MARC to make this change. The resulting MARC station is not a super-user station; the user of the station must log on to the system.
The RESTRICT SC form of the command can have a security key appended after it. This security key is then associated with the restricted ODT and is used to authorize use of the ??RESTRICT system primitive command to release the ODT from restriction.
If your site requires a high level of security, you might choose to restrict most of the ODTs used by the operations staff. This procedure enables you to audit the actions of those operators in the same way you audit the actions of any other logged-on user. You can then trace operations activities to specific operators.
If the operations staff is to work at restricted ODTs, take the following steps:
-
Use the RESTRICT command to restrict all the ODTs.
-
Assign each operator a unique usercode with SYSTEMUSER status. This procedure enables the operators to enter system commands on the Action line of MARC screens.
-
Assign privileged-user status to operators involved in file archiving and maintenance. This status enables them to copy and backup files belonging to other users.
An unrestricted ODT must be available for entering necessary system primitive commands.
There are two ways to assure that an unrestricted ODT is available:
-
Leave an ODT unrestricted, physically limit access to it to a very few operators, and manually log all use of it.
-
Use the RESTRICT SC <unit number list> (<security key>) form of the RESTRICT command to restrict an ODT. A chosen operator who knows the security key can use it to unrestrict the ODT, when necessary.
Because only one operator knows the key, that operator is responsible for all activity on the ODT when it is unrestricted.
Policy should require that the ODT be restricted again as soon as use permits.
At larger installations, you might choose to grant more than one operator access to an ODT on which primitive commands can be entered. In this case, take the following approach, which assumes that it is necessary for two operators to have access to unrestricted ODTs:
-
Restrict two ODTs, assigning each one a unique security key. Share the security key of one ODT with one operator and the other key with the other operator. Do not tell one operator both security keys.
This strategy has the effect of permitting each operator to unrestrict only one of the ODTs.
-
Inform these two operators that policy prohibits either one of them from unrestricting his or her ODT if the other's ODT is already unrestricted.
An operator can determine whether an ODT is unrestricted by using the PER SC form of the PER (Peripheral Status) system command. Another way an operator can tell whether an ODT is unrestricted is if the two ODTs with security keys are in proximity to each other.
These steps make it possible to attribute actions to individual operators.
This command performs the same function as the RESTRICT SC command, except that the ??RESTRICT primitive command applies exclusively to the ODT where it is entered.
The command has two forms:
??RESTRICT+ (<security key>) ??RESTRICT- (<security key>)
The first form of ??RESTRICT restricts the ODT on which the command is entered and automatically places that ODT under control of MARC. The second form releases from restriction the ODT on which the command is entered. Use of the ??RESTRICT primitive command does not require privileged status; however, when the ??RESTRICT–(<security key>) form of the command is used, the security key must match the security key entered at the time the ODT was made restricted.
To release the ODT from restriction, enter the ??RESTRICT– (<security key>) command. Once the ODT is unrestricted, remove the terminal from the control of MARC by using the system primitive command ??ODT. This command returns the terminal to ODT operation mode.
SL (Support Library) Command
The SL system command associates a function name with a specific library code file.
Security-Related Options
The SL command provides options for controlling the security-related attributes of a library code file, as outlined in SL Command Options.
Table 31. SL Command Options
Cautions About Possible Misuses of the SL Command
Misuse of the SL command might involve a nonprivileged user replacing an existing support library with one of his or her own creation. The new support library might function in a manner similar to the one it replaced until a privileged user used the library. At that time, the “false” support library could inherit the privileged status of the usercode and use this status to violate security.
The SL command can also permit execution of a code file that is unsafe or nonexecutable. If such a code file is made a support library, it can then be executed with a by-function library call. Applying the SL command to a code file that is TADS-capable might result in opening parts of system memory to unauthorized examination.
