Document revision date: 30 March 2001

When a project- or department-specific identifier is the owner of a directory, the space used by files created in the directory can be charged to the appropriate department or project rather than to the individual who creates them. When users work on multiple projects, they can charge their disk space requirements to the related project rather than to their personal accounts.

In setting up a directory for a resource identifier, you first create the disk quota authorization for the project identifier. For example, the following command invokes the System Management utility (SYSMAN) and assigns the identifier PROJECTX 2000 blocks of disk quota with 200 blocks of overdraft:

$ RUN SYS$SYSTEM:SYSMAN SYSMAN> DISKQUOTA ADD PROJECTX /PERMQUOTA=2000 /OVERDRAFT=200

After setting up the disk quota, you create the project directory. For example, the following DCL command creates the project directory [PROJECTX] and establishes the identifier PROJECTX as its owner:

$ CREATE/DIRECTORY [PROJECTX] /OWNER=[PROJECTX]

8.8.1.2.3 Setting Up the ACL

In setting up the directory [PROJECTX], you use an ACL to provide file access to project members. The following example shows how several ACEs are used to define access:

$ SET SECURITY [PROJECTX] /ACL= (- _$ (DEFAULT_PROTECTION,S:RWED,O:RWED,G,W),- (1) _$ (IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE),- (2) _$ (IDENTIFIER=PROJECTX,OPTIONS=DEFAULT,ACCESS=READ+WRITE+EXECUTE),- (3) _$ (CREATOR,ACCESS=READ+WRITE+EXECUTE+DELETE)) (4)

1. The Default Protection ACE sets up a protection code for files created within the directory. The ACE denies access to group and world users.
2. The first Identifier ACE gives holders of the PROJECTX identifier read, write, and execute access to the directory.
3. The second Identifier ACE guarantees that all files created in the directory will carry the first Identifier ACE.
4. The Creator ACE specifies that a user who creates a file in the PROJECTX directory will receive read, write, execute, and delete access to it.

Thus, when project member Crandall creates the file SEPTEMBER-REPORTS.TXT in the [PROJECTX] directory, the file receives the following security profile:

$ SHOW SECURITY/CLASS=FILE [PROJECTX]SEPTEMBER-REPORTS.TXT SEPTEMBER-REPORTS.TXT object of class FILE Owner: [PROJECTX] Protection: (System: RWED, Owner: RWED, Group, World) Access Control List: (IDENTIFIER=CRANDALL,ACCESS=READ+WRITE+EXECUTE+DELETE) (IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE)

Project members are not allowed to delete (or control) files created by others; however, the Creator ACE gives them delete access to files they have created.

Without a Creator ACE, project members each have complete access to files they have created in the directory. For example, Crandall would receive the following access to files created in the project directories:

$ SHOW SECURITY/CLASS=FILE [PROJECTX]SEPTEMBER-REPORTS.TXT SEPTEMBER-REPORTS.TXT object of class FILE Owner: [CRANDALL] Protection: (System: RWED, Owner: RWED, Group, World) Access Control List: (IDENTIFIER=CRANDALL,OPTIONS=NOPROPAGATE,ACCESS=READ+WRITE+EXECUTE+DELETE+CONTROL) (IDENTIFIER=PROJECTX,ACCESS=READ+WRITE+EXECUTE)

To negate this behavior, you can add a Creator ACE to the ACL that specifies ACCESS=NONE.

8.8.2 Setting Defaults for Objects Other Than Files

With the exception of files and pseudo-terminal (FT) devices, all classes of protected objects offer one or more template profiles that provide security elements for new objects. You can thus use a single mechanism to establish the default protection code, ACL, and ownership elements for objects. The operating system always stores these values so they are available from one system startup to the next. The SHOW SECURITY command displays the current default values for your particular site. Refer to Chapter 5 for a listing of the operating system's default values.

The operating system generates the security profiles of new objects from data stored by security class objects. These objects are all logical constructs used to keep track of such class elements as the valid access types, the templates, and the types of auditing that have been enabled. As Figure 8-2 shows, every class of protected object has a member in the security class. All members have a security profile template, except for files, which have their own rules.

Figure 8-2 Security Class Object

To display any class template, use the SHOW SECURITY/CLASS=SECURITY_CLASS command. The following command, for example, displays templates available for logical name tables. The logical name table object has the following three templates:

$ SHOW SECURITY/CLASS=SECURITY_CLASS LOGICAL_NAME_TABLE . . . Template: GROUP Owner: [TTSY,SYSTEM] Protection: (System: RWCD, Owner: R, Group: R, World:R) Access Control List: <empty> Template: JOB Owner: [TTSY,SYSTEM] Protection: (System: RWCD, Owner: RWCD, Group, World) Access Control List: <empty> Template: DEFAULT Owner: [TTSY,SYSTEM] Protection: (System: RW, Owner: RW, Group, World) Access Control List: <empty>

All objects in the security class are protected in the same manner as other objects. For this reason, any SHOW SECURITY display of a security class object begins with the security profile for the object itself. The following display shows a profile for the logical name table object in the security class. The object is owned by the system, and its protection code allows read access to any user category but allows write access only to system and owner categories.

$ SHOW SECURITY/CLASS=SECURITY_CLASS LOGICAL_NAME_TABLE LOGICAL_NAME_TABLE object of class SECURITY_CLASS Owner: [SYSTEM] Protection: (System: RW, Owner: RW, Group: R, World: R) Access Control List: <empty>

8.8.2.2 Modifying Class Templates

Security administrators and users with control access to a security class object can modify the elements of a given template with the following command:

SET SECURITY/CLASS=SECURITY_CLASS/PROFILE=TEMPLATE=template-name

The following command modifies the MAILBOX template for the device class. It changes the template values from a protection of S:RWPL,O:RWPL,G:RWPL,W:RWPL to a protection that disallows group and world access.

$ SET SECURITY/CLASS=SECURITY_CLASS/TEMPLATE=MAILBOX - _$ /PROTECTION=(S:RWPL,ORWPL,G,W) DEVICE

The operating system applies this value to all new mailboxes. To change the protection for each existing mailbox, enter an explicit SET SECURITY command for each existing mailbox. For example:

$ SET SECURITY/CLASS=DEVICE - _$ /PROTECTION=(S:RWPL,ORWPL,G,W) mailbox_name

The operating system saves the default object protections specified in security templates, so rebooting the system automatically ensures that all objects created after the reboot are created with the new default protections.

This section describes additional ways to restrict the data and resources available to users.

8.9.1 Precautions to Take When Installing New Software

When you install new software, you must address several security concerns. You want to ensure that you are not admitting software that will in any way corrupt or undermine your usual security precautions. You must also consider whether to install the software with any privileges. This section discusses the security aspects of installing new software.

8.9.1.1 Potentially Harmful Programs

New software can contain programs that are potentially harmful to your system. These programs, called Trojan horse programs, are designed to do damage and frequently include features that do the following:

• Pass privileges of the person running the program back to the author of the program
• Allow unauthorized access to the system
• Change protection of system files
• Patch the system (add special software to the operating system)
• Create jobs that scan for easily guessed passwords

To protect your system from this type of intrusion, always buy software from reputable sources. When training new users, stress the importance of avoiding use of software from an unknown source.

Another risk to programs and directories is known as the virus. While Trojan horse software must rely on the innocent user to unwittingly accept the damaging software by using it, the virus requires no user cooperation. It is a program that takes advantage of faulty file protection, working its way through your system and modifying command procedures and executable programs. By modifying command procedures, it can propagate by making use of user access rights and privileges.

Viruses are less of a problem in the OpenVMS environment than in an environment of personal computers. The OpenVMS protection features and the environment's larger scale and diversity make virus attacks more difficult. However, no environment that permits the sharing of software and data is immune from virus attacks.

The user's login command procedure is a prime target for this type of security breach. Login command procedures generally contain easily modified DCL commands and are executed regularly.

ACLs are also targets. File protection designed with users sharing access privileges allows this type of program to run through many users' programs, acquiring new privileges along the way.

Well-designed file protection is critical for protection from this type of security breach. Make sure that likely targets cannot be modified by users. For example, set up file protection so that your login command procedure permits at most read access to all other users. Also make sure the directory containing the login command procedure permits write access only to users in the system and owner categories.

Because most damage occurs when programs like these reach a target account with privileges, users with privileges should be especially cautious with the protection of their root directory, executable files, and command procedures. To deter Trojan horse attacks, users should never execute a command procedure or run an image in a privileged account without inspecting the command procedure or the image's sources. Application images should be rebuilt from source to ensure that the binary image reflects the accompanying source.

8.9.1.2 Installing Programs with Privilege

Some software requires privilege to run. You can extend the privilege to all users you expect will need to run the software, or you can install the program with the required privileges. When you install privileged software, you allow users to execute it whether or not they personally possess the required privilege. In effect, you extend the privilege to the process while it runs the software. While this offers some advantages, it also introduces several security-related dangers. Section 8.7 describes these options in greater detail.

8.9.2 Protecting System Files

Even on the most open system, you will want protection for the system software. Normally, Compaq delivers system programs and databases with adequate UIC protection. However, if for any reason you are dissatisfied with the default protection, you can change it with the techniques outlined in Chapter 4, provided you have the necessary SYSPRV privilege. You might also add an ACL to any file that you decide needs additional protection.

You can obtain a full listing of system files from the system manager's account during an OpenVMS installation with the following DCL command:

$ DIRECTORY/SECURITY/OUTPUT=SYSTEM_FILES.LIS SYS$SYSROOT:[*...]

Compaq recommends you generate such a listing and store it for reference. Regularly compare these values with current system file protection to ensure that no tampering has occurred. (The DCL commands DIRECTORY/SECURITY/OUTPUT and DIFFERENCES facilitate such checks.)

On Alpha systems, you can obtain a listing of system files and their protections from the read-only compact disc distribution media. Your OpenVMS software should have this set of protection codes following a correct installation.

On VAX systems, refer to Appendix B for a listing of system files and their protections. Your OpenVMS software should have this set of protection codes following a correct installation.

Table 8-4 provides a summary of DCL commands you use to set up and display file protection; these commands are described in the OpenVMS DCL Dictionary.

Table 8-4 DCL Commands Used to Protect Files

Command	Function
DIRECTORY/ACL	Displays the ACL for the file
DIRECTORY/OWNER	Displays the file owner's UIC
DIRECTORY/PROTECTION	Displays the file's protection code
DIRECTORY/SECURITY	Combines and displays file information produced by DIRECTORY/ACL, DIRECTORY/OWNER, and DIRECTORY/PROTECTION
EDIT/ACL	Invokes the access control list editor (ACL editor)
SET PROTECTION/DEFAULT	Establishes the default protection to be applied to all files subsequently created
SET SECURITY	Modifies the security profile of any object: the owner, protection code, and ACL
SHOW SECURITY	Displays the ownership, UIC protection code, and ACL of a protected object

The OpenVMS installation procedure does not initially install MAIL.EXE with any privileges (because MAIL.EXE does not require privileges to perform its functions). Prior versions of the OpenVMS operating system did include mechanisms that allowed MAIL.EXE to check, ignore, grant, or override certain privileges that a system manager might assign when reinstalling MAIL.EXE. Because these regulatory mechanisms sometimes created unexpected or undesirable conditions, they have been removed.

As indicated, Compaq provides default protection for the system programs that it provides. However, if you have a special requirement, you might examine the potential of ACLs for your needs. For example, you might use ACLs to restrict the use of system programs such as compilers. (Any number of considerations might prompt this action, ranging from performance to licensing issues.)

You might also ask if there are cases where you do not want some or all of your users to be able to initialize media. If there are, you can put an ACL to good use on the system program SYS$SYSTEM:INIT.EXE. Ensure that you grant no access to the world category in the UIC-based protection code. Then create an ACL for the file that grants access to specific users.

Similarly, if a department in your company has paid for a license to a software product, you may want to make that software available to them but not to others. Ensure that the world category receives no access through the standard UIC-based protection code, and create an entry in the ACL for that file that allows access through the department's identifier.

You may also find that ACL protection is relevant to protect your applications databases, limiting the access to certain users or to protected subsystems.

8.9.3 Restricting DCL Command Usage

There are several ways that you can affect the use of DCL commands by your users. Among them are the following:

• Impose ACLs on the system program files in the directories SYS$SYSROOT:[SYSEXE] and SYS$SYSROOT:[SYSLIB].
• Set the AUTHORIZE flag DISIMAGE to prevent use of the MCR or the RUN command. This prevents users from executing system or user-written images or from executing images defined as foreign commands. Because the DISIMAGE flag is enforced by the DCL command language interpreter (CLI), you must ensure that the account for which the DISIMAGE flag is set has access to the DCL CLI only. Use the DISIMAGE flag in conjunction with the AUTHORIZE flag DEFCLI or within a restricted account. (Setting the RESTRICTED flag for an account implicitly sets the DEFCLI flag.)
• Remove or modify DCL command definitions, and rebuild the DCL tables. (The OpenVMS System Management Utilities Reference Manual describes how to create command definitions.) Use the /CLITABLES qualifier in the user's UAF record to specify the modified tables. Also specify /FLAGS=DEFCLI to ensure that the user can log in only with the specified command language interpreter (CLI) and tables. Protect the original DCL tables from unauthorized access by imposing ACLs on the system program files in the directories SYS$SYSROOT:[SYSEXE] and SYS$SYSROOT:[SYSLIB]. In particular, protect SYS$LIBRARY:DCLTABLES.EXE and SYS$SYSTEM:CDU.EXE.

File encryption refers to the process of applying an algorithm to data to conceal its content. Decryption reverses the operation and converts encoded information back to its original content. If you need to copy proprietary software onto media for removal to another site, you might use file encryption. The software on the media is useless without the correct decryption code.

Different file encryption systems, both software and hardware, are available. Consult your Compaq support channel for information on which products are available in your country.

8.9.5 Protecting Disks

Disk scavenging is the process of reading magnetic imprints of data after deletion of the file header following a purge or delete operation. (When users delete files from the system, only the file header is deleted.) Until the data is overwritten, it is a potential target for disk scavenging. Sites with medium or high security needs should be concerned about this procedure.

After establishing overall security features, restrict access to disks containing valuable information by using UIC-based volume protection. Because disk scavenging is frequently performed by authorized users, consider implementing erasure patterns and high-water marking, as described in the following sections.

8.9.5.1 Erasing Techniques

There are several ways to implement erasing of disks.

• The inclusion of the /ERASE qualifier with the DELETE or the PURGE command causes the system to write an erasure pattern of zeros over the entire file location when you delete or purge that file. You can encourage users to use this qualifier voluntarily or make inclusion automatic by including the following command definitions in the system login command procedure (usually SYS$MANAGER:SYLOGIN.COM):

  DEL*ETE :== "DELETE/ERASE" PUR*GE :== "PURGE/ERASE"

  
  However, any user can bypass these definitions by adding the /NOERASE qualifier to the DELETE or the PURGE command.

• To guarantee erase-on-delete, turn on the feature for the entire volume by using the DCL command SET VOLUME/ERASE_ON_DELETE. When files are deleted, this command overwrites all files on the volume with the erasure pattern of zeros.
• To completely erase the volume and enable erase-on-delete for the volume at volume initialization, use the DCL command INITIALIZE/ERASE.
  By default, when erase-on-delete is enabled, the operating system writes a default data security erase (DSE) pattern of zeros, applied during a single write operation over the area. If you feel that the default pattern of zeros or the single rather than multiple number of erasures does not suit your requirements, you can use the $ERAPAT (Get Security Erase Pattern) system service to write a customized erasure pattern. See the description of $ERAPAT in the OpenVMS System Services Reference Manual for more information.

For sites with high-level security requirements, a random pattern is preferable to a fixed pattern. The technology is already available that can detect and use faint residual magnetic impressions. Thus, if you conclude there is sufficient danger that a disk might be removed and read using some of this specialized analysis equipment, you may need to rewrite the erasure pattern several times. You can learn how to customize the data security erase pattern to fit your needs by studying the information provided in the file SYS$EXAMPLES:DOD_ERAPAT.MAR.

Employ erasing patterns only on disks where the security needs are the greatest. Erasures are time-consuming and affect system performance.

	privacy and legal statement
6346PRO_020.HTML