HP OpenVMS Systems Documentation

OpenVMS User's Manual

Each system site has unique security requirements. For this reason,
every site should have a system security policy that outlines physical
and software security requirements for system managers and users. To
ensure system security, the OpenVMS operating system controls both
access to the system and access to any object that contains shareable
information. These objects, such as devices, volumes, logical name
tables, files, and queues, are known as protected
objects. All protected objects list a set of access
requirements that specify who has a right to access the object in a
given manner.

The OpenVMS Guide to System Security describes the security features available with the
operating system and the tasks that system managers can perform to
maintain account and system security. This chapter describes some of
the ways OpenVMS protects and audits your system resources. It includes
information about:

Displaying the rights identifiers of your process

Security profile of objects

Interpreting protection codes

Default file protection

Accessing files across networks

Auditing access to your account and files

For additional security information, refer to the following:

The OpenVMS Guide to System Security, for information about protecting objects and
system security in general

The OpenVMS DCL Dictionary or online help, for information about commands
discussed in this chapter

You can familiarize yourself with OpenVMS security features in the
following ways:

Know the rights identifiers associated with your
process --- Rights identifiers determine what resources you can access.
If your process does not have the appropriate identifiers, you may be
unable to access certain protected objects. See Section 10.1 for
information about displaying your rights identifiers.

Display security profiles of protected objects --- A security
profile contains information about protected objects. You can change
the security profile of objects that you own to make them accessible or
inaccessible to other users. See Section 10.2 for information
about security profiles.

Know how to access files across networks --- This can be
accomplished by using access control strings or proxy login accounts.
See Section 10.5 for information about accessing remote files.

Audit access to your account and files --- This can be
accomplished by closely observing any login messages and by working in
conjunction with your system manager to audit your files. See
Section 10.6 for information about auditing access to your account and
files.

All processes that attempt to access protected objects carry
credentials known as rights identifiers. All protected objects list a
set of access requirements that specify who has a right to access the
object in a given manner. If an accessing process' rights identifiers
do not match those of the object, access is denied.

The following example shows how to display the identifiers for your
current process using the SHOW PROCESS command:

Because the operating system supports many users simultaneously, it has
built-in security mechanisms to prevent one user's activities from
interfering with another's. Protection codes, access controls, and
hardware design together protect the use of memory, shareable devices,
and data so many users can share the system. An object's security
profile is comprised of the user identification code (UIC), the ACL,
and the protection codes assigned to that object. You can display or
modify the security profile of any object that you own.

To see the security profile of any protected object, use the DCL
command SHOW SECURITY. For example, the following command requests
security information about the file 95_FORECAST.TXT:

The display indicates the file 95_FORECAST.TXT is owned by user Greg.
It also lists the file's protection code, which gives read, write,
execute, and delete access to system users and to the owner. The code
grants read and execute access to group users and provides no access to
world users. (See Section 10.3 for further explanation.) There is no
ACL on the file.

You can provide new values for the owner, protection code, or ACL of a
protected object, or you can copy a profile from one object to another
by using the SET SECURITY command.

For example, the SHOW SECURITY display in Section 10.2 shows the file
95_FORECAST.TXT is owned by user Greg. As owner, he can change the
protection code for that file. Originally, the code gave no access to
users in the world category. Now, Greg has changed that to allow read
and write access to world users:

$ SET SECURITY/PROTECTION=(W:RW) 95_FORECAST.TXT

The SHOW SECURITY command verifies the new protection code for the file:

Categories include system (S), owner (O), group (G), and world (W).
Each category can be abbreviated to its first character. Categories
have the following definitions:

System

Any user process or application whose UIC is in the range 1 through 10
(octal), has SYSPRV privilege, or is in the same group as the owner and
holds GRPPRV.

Owner

Any user process or application whose UIC is identical to the UIC of
the object.

Group

Any user process or application whose group UIC is identical to the
group UIC of the object.

World

Any user process or application on the system.

When specifying more than one user category, separate the categories
with commas and enclose the entire code in parentheses. You can specify
user categories and access types in any order.

A null access specification means no access, so when you omit an access
type for a user category, that category of user is denied that type of
access. To deny all access to a user category, specify the user
category without any access types. Omit the colon after the user
category when you are denying access to a category of users.)

For files, an access list includes read (R), write (W), execute (E), or
delete (D) access types. The access type is assigned to each ownership
category and is separated from its access types with a colon (:). File
access types have the following meanings:

Read

Gives you the right to read, print, or copy a disk file. With directory
files, read access gives you the right to read or list a file and use a
file name with wildcard characters to look up files. Read access
implies execute access.

Write

Gives you the right to write to or change the contents of a file, but
not delete it. Write access allows modification of the file
characteristics that describe the contents of the file. With directory
files, write access gives you the right to insert or delete an entry in
the catalog of files.

Execute

Gives you the right to execute a file that contains an executable
program image or DCL command procedure. With a directory file, execute
access gives you the right to look up files whose names you know.

Delete

Gives you the right to delete the file. To delete a file, you must have
delete access to the file and write access to the directory that
contains the file.

A new file receives the default UIC-based protection and the default
access control list (ACL) of its parent directory. An ACL is a
collection of entries that define the access rights a user or group of
users has to a particular protected object such as file, directory, or
device.

You can use either default UIC protection or default ACL protection to
override the default UIC-based protection given to new files.

The operating system provides each process with the following UIC-based
protection:

(S:RWED, O:RWED, G:RE, W)

By default, users with a system UIC and the owners of objects have full
access to the object, users in the same UIC group as the object owner
have read and execute access to the object, and all other users are
denied access to the object. To change the default protection for files
that you create, enter the SET PROTECTION command with the /DEFAULT
qualifier. For example, if you enter the following command in your
login command procedure, you grant all processes read and execute
access to any files that you create. (Remember that you must execute
the login command procedure for this command to execute.)

You can override default UIC protection for specified directories or
subdirectories by placing a default protection access control
entry (ACE) in the ACL of the appropriate directory file. The
default protection specified in the ACE is applied to any new file
created in the specified directory or subdirectory of the directory.
The following ACE, which must be in the ACL of a directory file,
specifies that the default protection for that directory and the
directory's subdirectories allow system and owner processes full
access, group processes read and execute access, and world users no
access.

A renamed file's protection is unchanged. A new version of an existing
file receives the UIC-based protection and ACL of the previous version.
(Use the /PROTECTION qualifier of the BACKUP, COPY, CREATE, and SET
FILE commands to override the default UIC-based protection.)

You can explicitly specify UIC-based protection for a new file with the
/PROTECTION qualifier (valid with the BACKUP, COPY, and CREATE
commands).

You can change the UIC-based protection on an existing file with the
SET SECURITY/PROTECTION command.

After a file is created and you have created an ACL for the file, you
can modify the ACL and add as many entries to it as you want. The
protection specified by the ACL overrides the file's user
identification code protection.

In the following example, UIC-based protection is specified:

$ CREATE MAST12.TXT/PROTECTION=(S:RWED,O:RWED,G,W)

In the following example, the UIC-based protection is changed on the
file MAST12.TXT:

You can include network access control strings in the file
specifications of DCL commands that perform operations across the
DECnet for OpenVMS network. The access control strings permit a user on
a local node to access a file on a remote node.

An access control string consists of the user name for the remote
account and the user's password enclosed within quotation marks, as
follows:

NODE"username password"::disk:[directory]filename.filetype

Caution

Because access control strings include sufficient information to allow
someone to break in to the remote account, they create serious security
exposure.

Avoid revealing the information on either hardcopy or video
terminals. If you use a hardcopy terminal, dispose of the output
properly. If you use a video terminal, clear the screen and empty the
recall buffer with the DCL command RECALL/ERASE when the network job is
completed. This prevents another user from seeing the password, either
by displaying the command line with the Ctrl/B sequence or with the DCL
command RECALL/ALL.

Do not place networking commands that include access control
strings in command procedures where they would be likely targets for
discovery.

If you must put access control strings in your command procedures,
provide these files with optimum file protection.

To avoid the need for access control strings, you might prefer to use
proxy login accounts. Proxy logins let you access files across a
network without specifying a user name or password in an access control
string. Thus, proxy logins have the following security benefits:

Passwords are not echoed on the terminal where the request
originates.

Passwords are not passed between systems where they might be
intercepted in unencrypted form.

Passwords are not needed in command files to perform the remote
access steps.

Before you can initiate a proxy login, the system or security
administrator at the remote node must create a proxy account for you.
Proxy accounts, like regular accounts, are created with the OpenVMS
Authorize utility (AUTHORIZE). They are usually nonprivileged accounts.
Security administrators can allow you access to one default proxy
account and up to 15 other proxy accounts.
While proxy logins require more setup effort on the part of system
managers, they provide more secure network access and eliminate the
need for users to enter access control strings.

The following example illustrates the differences between a normal
network login request and a proxy login request. For each example, the
following conditions exist:

The user KMAHOGANY has two user accounts:

An account on node BIRCH with the password "XYZ123ABC"

An account on node WALNUT with the password "A25D3255"

KMAHOGANY has logged in to node BIRCH.

KMAHOGANY wants to copy the file BIONEWS.MEM from the default
device and directory of the account on the node WALNUT.

The following figure shows these conditions.

The user KMAHOGANY could use an access control string to copy the
file BIONEWS.MEM, as follows:

$ COPY WALNUT"KMAHOGANY A25D3255"::BIONEWS.MEM BIONEWS.MEM

Notice that the password A25D3255 echoes. Anyone who observes the
screen can see it.

If KMAHOGANY has proxy access from node BIRCH to the account on
node WALNUT, the command for copying the file BIONEWS.MEM is as follows:

$ COPY WALNUT::BIONEWS.MEM BIONEWS.MEM

KMAHOGANY does not need to specify a password in an access control
string. Instead, the system performs a proxy login from her account on
node BIRCH into her account on node WALNUT. There is no exchange of
passwords.

Your security administrator can also authorize groups of users from
foreign nodes to share in the use of a general access proxy account.
For example, the security administrator at node WALNUT can create a
general access account with the following conditions:

The user name GENACCESS.

Access limited to network logins.

A password known only to the owner of the account. (None of the
remote users need to know it.) This helps to protect the account.

The default device and directory STAFFDEV:[BIOSTAFF].

If the security administrator grants BIRCH::KMAHOGANY proxy access to
the GENACCESS account, the user KMAHOGANY can copy the file BIONEWS.MEM
by entering the following command:

$ COPY WALNUT::[KMAHOGANY]BIONEWS.MEM BIONEWS.MEM

Note that KMAHOGANY must specify the directory [KMAHOGANY] because the
file BIONEWS.MEM is not in the default device and directory for the
GENACCESS account (STAFFDEV:[BIOSTAFF]). In addition, the protection
for the file BIONEWS.MEM must permit access to the GENACCESS account.
Otherwise, the command fails.

If you have access to more than one proxy account on a given node and
you do not want to use the default proxy account, specify the name of
the proxy account. For example, to use a proxy account called PROXY2
instead of the GENACCESS account (the default), KMAHOGANY enters the
following command:

$ COPY WALNUT"PROXY2"::[KMAHOGANY]BIONEWS.MEM BIONEWS.MEM

This command uses the PROXY2 account to copy the file BIONEWS.MEM from
the [KMAHOGANY] directory on node WALNUT.

The OpenVMS system maintains information in your UAF record about the
last time you logged in to your account. Your security administrator
decides whether the system should display this information at login
time. Sites with medium to high security requirements frequently
display this information and ask users to check it for unusual or
unexplained successful logins and unexplained failed logins.

If there is a report of an interactive or a noninteractive login at a
time when you were not logged in, report it promptly to your security
administrator. Also change your password. The security administrator
can investigate further by using accounting files and audit logs.

If you receive a login failure message and cannot account for the
failure, it is likely that someone has been trying to access your
account unsuccessfully. Check your password to ensure that it adheres
to all recommendations for password security described in
Section 1.9. If not, change your password immediately.

If you expect to see a login failure message and it does not appear or
if the count of failures is too low, change your password. Report
either of these indications of login failure problems to your security
administrator.

The security administrator can select one or more types of events that
warrant special attention when they occur. When such an event is
detected, the security administrator directs the system to send an
audit to the system security audit log file or an alarm to terminals
enabled as security operator terminals. For example, the security
administrator might identify one or more files for which write access
is prohibited. An audit can be enabled or an alarm can be set to
indicate attempted access to these files.

If you suspect a break-in to your account, change your password. You
might want to request that your security administrator implement
auditing on sensitive files.