Document revision date: 15 July 2002

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

Security Features

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:

$ SHOW PROCESS/ALL 25-NOV-2002 15:23:18.08 User: GREG Process ID: 34200094 Node: ACCOUNTS Process name: "GREG" Terminal: VTA2195: TNA2170: (Host: 16.32.123.45 Port: 6789) User Identifier: [DOC,GREG] (1) Base priority: 4 Default file spec: WORK1:[GREG.FISCAL_96] Number of Kthreads: 1 Devices allocated: ACCOUNTS$TWA2: Process Quotas: . . . Process rights: INTERACTIVE (2) LOCAL (3) SALES (4) MINDCRIME resource (5) System rights: SYS$NODE_ACCOUNTS (6)

There are three types of rights identifiers: UIC, environmental, and general. Output from the SHOW PROCESS command displays all three:

1. UIC identifier, indicating user Greg is a member of the DOC group
2. Environmental identifier, indicating user Greg is an interactive user
3. Environmental identifier, indicating user Greg is logged in locally
4. General identifier, indicating user Greg is also a member of the SALES group
5. General identifier, indicating Greg holds the MINDCRIME identifier with the resource attribute so he can charge disk space to the identifier
6. Environmental identifier, indicating user Greg is working from the ACCOUNTS node

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:

$ SHOW SECURITY 95_FORECAST.TXT WORK_DISK$:[GREG]95_FORECAST.TXT;1 object of class FILE Owner: [ACCOUNTING,GREG] Protection: (System: RWED, Owner: RWED, Group: RE, World) Access Control List: <empty>

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.

10.2.1 Modifying a Security Profile

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:

$ SHOW SECURITY 95_FORECAST.TXT 95_FORECAST.TXT object of class FILE Owner: [GREG] Protection: (System: RWED, Owner: RWED, Group: RE, World: RW) Access Control List: <empty>

10.3 Interpreting Protection Codes

A protection code controls the type of access allowed (or denied) to a particular user or group of users. It has the following format:

[category: list of access allowed (, category: list of access allowed,...)]

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.

10.4 Default File Protection

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.

10.4.1 Default UIC Protection

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.)

$ SET PROTECTION = (S:RWED,O:RWED,G:RE,W:RE)/DEFAULT

10.4.2 Default ACL Protection

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.

$ SET SECURITY/ACL = (DEFAULT_PROTECTION,S:RWED,O:RWED,G:RE,W:) [JONES]PERSONAL.DIR

To specify a default identifier ACE to be copied to the ACL of any file subsequently created in the directory, specify the DEFAULT option in the directory file's identifier ACL.

The ACE shown in the following example is applied to a directory file and denies network users access to all files created in the directory:

$ SET SECURITY/ACL = (IDENTIFIER=NETWORK,OPTIONS=DEFAULT,ACCESS=NONE) - _$ [JONES]PERSONAL.DIR

10.4.3 Renaming Files

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.)

10.4.4 Explicit File 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:

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

10.5 Accessing Files Across Networks

The following sections describe how to access files across networks.

10.5.1 Access Control Strings

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

To protect access control string information, do the following:

• 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.

10.6 Auditing Access to Your Account and Files

Although it is the security administrator's job to monitor the system for possible break-in attempts, you can assist the security administrator in auditing access to your account and files.

10.6.1 Observing Your Last Login Time

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.

	privacy and legal statement
6489PRO_025.HTML