|
|
Updated:
11 December 1998
|
OpenVMS Guide to System Security
C.4.1 Protecting Files
The files comprising the TCB are correctly protected when the operating
system is installed; however, the protection can be altered by
sufficiently privileged users. Appendix B of this guide describes
the correct file protection of operating system files.
When installing an OpenVMS operating system, avoid modifying any system
files except those specific to your site. You want to maintain the
security of the base operating system.
C.4.2 Privileges for Trusted Users
Certain privileges allow the holder to bypass normal file and memory
access controls directly or indirectly and, therefore, must not be
granted to persons other than the system manager, security
administrator, or other trusted users. Privileges in four categories
are appropriate only for trusted users: Objects, All, System, and
Group. Refer to Table 8-2 for the privileges belonging to each of
these categories. The privileges themselves are described in detail in
Appendix A.
Privileges in the Objects and All categories allow the holder to
violate the isolation of the TCB from untrusted users. Privileges in
the System category allow the holder to interfere with normal system
operation and cause denial of service, but they do not allow the holder
to actually violate object access controls. Some privileges in the
System category also allow access controls to be ultimately bypassed.
Privileges in the Group category permit the holder to interfere with
the operations of others in the same group. The GRPPRV privilege, in
particular, permits the holder to violate normal access controls within
that holder's group because it grants access (through the system field
of the protection code) to objects owned by subjects sharing the same
group UIC.
All trusted users should be familiar with all the effects of any
operations they perform. In particular, they need to know all software
products an operation might use because a trusted user's privileges can
allow untrusted software to perform operations that OpenVMS security
policy would otherwise preclude.
C.4.3 Privileges for Untrusted Users
Untrusted users can hold any privilege in the Normal and Devour
category with the exception of GRPNAM. Exercise caution in granting
privileges from the Devour category, however, for they permit the
holder to consume resources without limit, thereby causing possible
denial of service and interference with the operations of other users
on the system. Table C-2 lists privileges allowed to untrusted
users.
Table C-2 Privileges for Untrusted Users
Category |
Privilege |
Activity Permitted |
Normal
|
NETMBX
TMPMBX
|
Create network connections
Create temporary mailbox
|
Devour
|
ACNT
ALLSPOOL
BUGCHK
EXQUOTA
PRMCEB
PRMGBL
PRMMBX
SHMEM
|
Disable accounting
Allocate spooled devices
Make bugcheck error log entries
Exceed disk quotas
Create/delete permanent common event flag clusters
Create permanent global sections
Create permanent mailboxes
Create/delete structures in shared memory
|
C.4.4 Physical Security
Physical and environmental security are critical to the secure
operation of the system. All physical components of the TCB
require adequate protection, or unauthorized people can jeopardize the
system's security. Because the following practices and features
jeopardize the security of the TCB, they must not be used in a C2
environment:
- Do not put the console terminal in a public area. The console
terminal must always be physically secured because it controls
operation of the CPU and, consequently, operation of the system.
- Do not leave the console password disabled if the console has the
password feature. (It is available on some VAXstation 3100s, most later
models, and the evaluated Alpha models.) The console password prevents
unauthorized personnel from using commands to boot from alternate
media, to perform a conversational boot, or to modify memory.
- Do not allow modems. Modems provide an avenue into the trusted
system, and the possibilities for compromising system security are
enormous.
- Do not leave remote diagnostics enabled. Remote diagnostics provide
another avenue into the trusted system. Disable remote diagnostics by
placing the diagnostics switch in the off position.
- Do not allow authentication cards. These devices are not supported
in a C2 evaluated configuration.
- Do not permit physical access to cluster communication media.
Intruders can penetrate the system if they have physical access to any
processor or cable.
The operating system protects all
communications interfaces against world access by default. This
includes the CI and local area network (LAN) devices, such as the
Ethernet, DSSI, FDDI, and SCSI. The CI interface is a trusted interface
among members of a CI cluster and is inaccessible to unprivileged
users. Unprivileged users should not be granted access to LAN devices.
- Do not allow untrusted users to access the HSC console. Place the
console in an area where only authorized personnel can use it. You do
not want untrusted users to perform sensitive operations, such as
backing up and restoring disk volumes.
- Do not allow users to read printer output of other users. Protect
printer output so users have access only to their own data.
- Do not leave storage media, such as disks, tapes, and compact
discs, where unauthorized users can access it. Once a user has the
media in their possession, they can read and modify its contents.
C.5 Configuring a C2 System
This section discusses C2 constraints on the use of OpenVMS features.
It includes the following topics:
- Requirements for maintaining individual accountability
- Correct management of the audit log file
- Correct use of terminals, volumes, and printers
- Cluster requirements
- Required settings for system parameters
- Commands and software excluded from system operation
C.5.1 Keeping Individuals Accountable
The proper use of names, UICs, and passwords ensures that individual
accountability is enforced by the OpenVMS operating system. As a
general practice, Compaq recommends that you use generated passwords on
privileged accounts. Because the following practices and features
result in the loss of individual accountability, they must not be used
in a C2 environment:
- Do not assign the same UIC to more than one user. The UIC is used
as the universal internal user identifier; therefore, unique UICs must
be assigned to all users.
- Do not allow open accounts. Lack of a password makes an account
available to all users aware of its identity. The system manager can
prevent open accounts by never setting null passwords with the
Authorize utility (AUTHORIZE) and by ensuring that all accounts are set
up with a nonzero minimum password length.
- Do not allow group accounts. Individual accountability is lost when
more than one person shares an account. Each user must be given a
unique account.
- Do not allow guest accounts because they allow multiple users
access to resources on your system through a common account. Most needs
for a guest account can be handled by special proxy login accounts.
- Do not enable autologin. The automatic login facility (ALF)
associates an account with a particular terminal instead of a
particular person and, therefore, causes a loss of individual
accountability.
- Do not initiate network proxy accounts for groups. In order to
preserve individual accountability, each individual in a network must
be given a unique network proxy account on each node to which that user
has access. Assign the same user name and UIC on all applicable nodes,
and then set up individual proxies among the corresponding accounts.
- Do not grant privileged access to proxy accounts.
- Do not grant the DBG$ENABLE_SERVER identifer in the rights database
unless it is needed to run the debug server.
- Do not log operator HSC activities to a video terminal. You must
use a hardcopy printer to log operator activities so it is possible to
associate a specific system operation with the person performing it.
- Ensure users are familiar with the restrictions on the use of
access control strings in the evaluated configuration. (See page 3-15
in the SFUG.) Specifically, the use of access control strings is not
permitted in an evaluated configuration. The proxy login accounts
should be used in the evaluated configuration.
- Do not allow operators to perform any task from the HSC console
without signing the operator log. The sign-in log is required to track
who performed HSC console operations and when. Together with the
hardcopy output, the log provides a record of HSC operations.
C.5.2 Managing the Auditing Trail
The security-auditing system lets you to track security-relevant
activity on the system provided you manage it correctly. To follow a
trail of activity in the audit logs, you must have complete and
accurate records. Security event messages can be recorded in the
security audit log file and on any terminal designated to receive
security-class event messages. Because the following practices
jeopardize a site's ability to track security-relevant events in the
system, they must not be used in a C2 environment:
- Do not disable the audit server or OPCOM. The audit server must be
running to process audit event messages, and OPCOM is required to
deliver alarms.
- Do not use multiple audit log files in a cluster. You must use the
clusterwide audit log file, which the system establishes by default.
Without this clusterwide file, it is difficult to show the precise
relationship among events that occur on various cluster nodes during
any given time period.
- Do not use a video terminal as a security operator terminal. You
must enable a hardcopy terminal to receive security event messages.
- Do not place the security operator terminal in a public location.
Physically secure the terminal so that only authorized personnel have
access to it.
- Do not ignore the audit log file. You must review the security
audit log file regularly for all audit events. In particular, notice
whether any auditing modifications have been made. (Any use of the SET
AUDIT command indicates some modification has taken place.) The audit
log file is normally protected against reading or modification by
unauthorized users.
- Do not allow tampering with the audit log file. Alway place
security-auditing ACEs on the system security audit log file to enable
auditing of all attempts to modify or delete the audit log file.
For example:
$ SET SECURITY SYS$MANAGER:SECURITY.AUDIT$JOURNAL -
_$ /ACL=((ALARM=SECURITY,ACCESS=WRITE+DELETE+CONTROL+SUCCESS+FAILURE),-
_$ (AUDIT=SECURITY,ACCESS=WRITE+DELETE+CONTROL+SUCCESS+FAILURE))
|
The operating system audits ACL events by default, and you can verify
this setting with the DCL command SHOW AUDIT. If necessary, reenable
ACL alarms and audits with the following command:
$ SET AUDIT/ALARM/AUDIT/ENABLE=ACL
|
- Do not allow trusted users to operate without supervision. You
should audit the actions of trusted users (such as operators, managers,
and security administrators) by enabling auditing of changes to the
authorization database. Also place security-auditing ACEs on captive
login command procedures and the directories containing them so you can
detect modifications.
C.5.3 Reusing Objects
Before allocating memory or protected objects like volumes and devices
to new users, sites must ensure that they are free of old data. The
memory management subsystem protects against the reuse of system memory
pages, and it cannot be defeated. Because the following practices
jeopardize the clearing of old data from volumes and terminals before
reallocation, they must not be followed in a C2 environment:
- Do not disable high-water marking on system disk volumes. The
high-water marking and erase-on-delete features of the operating system
protect against reuse of disk blocks (see Section 8.9.5).
- Do not allow users to leave their terminals on after logging out.
They must turn off their terminals so the logout message is erased. The
logout message reveals a user name and sometimes a node name. Moreover,
by turning off the terminal, terminal characteristics are reset, and
memory buffers are cleared. Some Trojan horse attacks use hardware
frame buffers and the answerback capabilities that are built into newer
terminals.
- Do not recycle tape volumes to new users until the tapes have been
erased externally by operations personnel. The operating system
provides no protection against reuse of tape volumes. (This is because
the OpenVMS operating system considers tape drives to be single-user
devices. It provides tape protection only at the volume level; an
entire volume can be assigned ownership and protection but individual
files on the volume cannot.)
Compaq recommends that sites clear printers between jobs to ensure that
print jobs do not interfere with one another. A security administrator
can reset printers automatically at the start or end (or both) of each
job by associating a device control library with the print queue.
Consult the documentation supplied with your printer to determine the
appropriate reset sequence, and then refer to the OpenVMS System Manager's Manual for
directions on adding that sequence to a library and associating the
library with the queue.
C.5.4 Configuring Clusters
All valid cluster configurations, when configured as common environment
clusters, fully support the OpenVMS security features. Because the
following practices and features result in the loss of a common
environment cluster, they must not be used in a C2 environment.
Note
OpenVMS clusters can consist of VAX and Alpha nodes.
|
- Do not operate with multiple authorization databases or audit log
files. A clustered system is considered a single security and
management domain and must operate with a shared authorization database
and a single audit log file. If you have multiple system disks for
performance reasons, system managers should ensure that the system
files are identical.
The following files must be shared across all
cluster members:
NETOBJECT.DAT
|
NET$PROXY.DAT
|
NETPROXY.DAT
|
QMAN$MASTER.DAT
|
RIGHTSLIST.DAT
|
SYS$QUEUE_MANAGER.QMAN$QUEUES
|
SYSUAF.DAT
|
SYSUAFALT.DAT
|
VMS$AUDIT_SERVER.DAT
|
VMSMAIL_PROFILE.DATA
|
VMS$OBJECTS.DAT
|
VMS$PASSWORD_DICTIONARY.DATA
|
VMS$PASSWORD_HISTORY.DATA
|
VMS$PASSWORD_POLICY.EXE
|
- Do not attach nodes to the cluster that are not part of the
evaluated system. The evaluated OpenVMS configuration includes DECnet
software bounded to the cluster environment that is a single security
domain. All physically attached nodes must be part of the evaluated
system.
C.5.5 Starting Up and Operating the System
A C2 system is the shipped system that has been configured according to
the guidelines in this appendix. When configuring your system, you must
observe the following guidelines:
- Set security-sensitive parameters to the following values:
System Parameter |
Setting |
Description |
LGI_CALLOUTS
|
0
|
Disables use of LOGINOUT callouts
|
LOAD_PWD_POLICY
|
0
|
Disables site-specific password filters
|
MAXSYSGROUP
|
7
|
Sets the maximum UIC value for the system category to single-digit UICs
|
NISCS_CONV_BOOT
|
0
|
Disables use of a conversational system bootstrap
|
RMS_FILEPROT
|
65,280
|
Sets a default protection code for user's files of S:RWED,O:RWED,G,W
|
SECURITY_POLICY
|
0
|
Disables certain unevaluated operating system components
|
STARTUP_P1
|
" "
|
Disables the minimum sequence of the startup procedure
|
- Do not use the CONNECT CONSOLE command to connect to a console
storage device, except on a VAX 9000 system. On a VAX 9000 system, use
the console command SET SPU_UPDATE OFF to isolate the storage device.
Some console subsystems support a storage device, such as a tape or
disk, that is used to load system and diagnostic programs; however, the
operating system also supports the capability to read and write data on
a console storage device, so it is neccessary to isolate the console
storage device from the system. This command is not available on the
evaluated Alpha platforms.
- Do not enable console operations by booting with FYDRIVER. FYDRIVER
would make two DCL commands operative:
- SET HOST/HSC allows a user to initiate certain HSC console
operations from an OpenVMS node
- SET HOST/DUP is used for configuring DSSI devices
If you need to install FYDRIVER during system startup to configure
your HSC devices and disks or perform necessary diagnostics, then
perform a minimum boot and install FYDRIVER so you can configure
devices and so on. Then shut down the system and reboot without
FYDRIVER.
C.5.6 Forcing Immediate Reauthentication of a Specified Subject After a Change in Access Rights
A system or security administrator may force an untrusted subject to
reauthenticate himself or herself at any time. This might be necessary
when the subject's access rights have been modified. The procedure is
as follows and can be performed only by a trusted subject.
- Make the changes to the subject's authorization record in the
authorization file.
- Obtain the owner's UIC of the subject from the authorization file.
- Enter the SYSMAN utility.
- Use the SYSMAN utility to identify all processes owned by the
subject.
- In an OpenVMS Cluster environment, set the SYSMAN environment
clusterwide. If you are not in an OpenVMS Cluster environment, skip
this step.
- Use SYSMAN DO SHOW SYSTEM/FULL to obtain a listing of all processes
on the system or OpenVMS cluster. This command also lists the owner UIC
and system PID of each process. Record this information.
- From SYSMAN, stop every process on every system that is owned by
the subject.
Note: Any process created by the subject after Step 4
is bound by the new access rights and does not need to be deleted.
Therefore, this is not a recursive procedure.
- In the OpenVMS cluster environment, set the SYSMAN environment to
point to only one node. If you are not in the OpenVMS cluster
environment, skip this step.
- For each process on the system to be deleted, identify the PID from
Step 2 and use the SYSMAN DO STOP/ID=pid command to stop the job.
- Repeat Steps a and b until all desired processes on all nodes of
the cluster have been stopped.
C.6 Checklist for Generating a C2 System
The previous sections of this appendix describe the U.S. government
requirements for running the OpenVMS operating system in a C2
environment. The following list reviews the government's security
requirements:
Installing the System
- Did you perform a full installation (not an upgrade) as described
in the OpenVMS VAX Version 6.1 Upgrade and Installation Manual?
Using Evaluated Components
- Is all hardware in your configuration listed on the evaluated
hardware list? (See Final Evaluation Report, Compaq Equipment
Corporation, OpenVMS VAX and SEVMS Version 6.0.)
- Have you excluded the following software products: DECdns,
LASTport, LASTport/DISK, LAT?
- Do system files have the same protection as when Compaq delivered
them to you? (See Appendix B.)
- Did you avoid installing DECwindows software or other privileged
layered products?
Making Individuals Accountable
- Have you trained privileged users so they understand the effect of
operations they may perform?
- Does each user have a unique UIC?
- Do all accounts have passwords of nonzero length?
- Does each user have a separate account?
- Have you eliminated any guest accounts?
- Have you disabled all autologins?
- Does each user have a unique proxy?
- Are all proxy accounts nonprivileged?
- Do you log operators' HSC activities on a hardcopy printer?
- Does the HSC console have a sign-in log, and are your operators
trained to use it?
- Did you ensure that users are familiar with the restrictions on the
use of access control strings in the evaluated configuration?
Managing the Audit Reporting System
- Are the audit server and OPCOM processes running?
- Do you have one audit log file for the entire cluster?
- Are you using a hardcopy terminal as the security operator terminal?
- Is the security operator terminal accessible only to authorized
personnel?
- Do you have a procedure for reviewing the audit log file on a
regular basis?
- Does the audit log file have both Audit and Alarm ACEs?
- Are the Authorization and ACL event classes enabled?
- Did you put Audit ACEs on all captive login command procedures and
their home directories?
Reusing Disks, Tapes, and Terminals
- Is high-water marking enabled on system disk volumes?
- Are users trained to shut off their terminals after logging out?
- Do you have a procedure for erasing tapes before they are used
again?
Building a Single Security Domain
- Does your cluster have only one copy of the following files?
NETOBJECT.DAT
|
NET$PROXY.DAT
|
NETPROXY.DAT
|
QMAN$MASTER.DAT
|
RIGHTSLIST.DAT
|
SYS$QUEUE_MANAGER.QMAN$QUEUES
|
SYSUAF.DAT
|
SYSUAFALT.DAT
|
VMS$AUDIT_SERVER.DAT
|
VMSMAIL_PROFILE.DATA
|
VMS$OBJECTS.DAT
|
VMS$PASSWORD_DICTIONARY.DATA
|
VMS$PASSWORD_HISTORY.DATA
|
VMS$PASSWORD_POLICY.EXE
|
- Are all nodes in the cluster part of the C2 configuration?
Starting the System
- Did you set security-sensitive parameters to the following values?
LGI_CALLOUTS
|
0
|
LOAD_PWD_POLICY
|
0
|
MAXSYSGROUP
|
7
|
NISCS_CONV_BOOT
|
0
|
RMS_FILEPROT
|
65,280
|
SECURITY_POLICY
|
0
|
STARTUP_P1
|
" "
|
- Is the CONNECT CONSOLE command disabled? (On VAX 9000 systems, is
the SET SPU_UPDATE_OFF command in effect?)
- Have you excluded FYDRIVER from your system?