Test the protection of specified files.

Violation reports

Description

This element tests protection of specific files for which you want tighter control than general files on the system. It is also the only element that tests for the presence (or absence) of particular audit or alarm ACEs (access control entries) within an ACL (access control list).

There are three types of tests included:

• Basic file protection tests ABSOLUT%% and PERCENT%%
  For certain files you may require tighter protection than your general standards.
• Identifier ACE tests ACLNO%%%
  Use of UIC identifiers directly in access control lists leads to problems if user responsibilities are changed, since control of the access they have been granted is distributed throughout the system. The purpose of this test is to ensure that identifiers used in Identifier Access Control Entries are of acceptable types.
  In addition, for certain files you might want to prohibit all forms of ACL-based access.
• Alarm and Audit ACE tests AL* and AU* (for failure and success audits)
  Auditing is the only defense against access by highly privileged users (coupled with review of the audit logs). But in some cases even for files that are not tightly protected you might want to audit access to ensure you have a record of how they are used.

This element uses limits and exemptions in a different fashion than most. Each file to be tested must be specified in an exemption, with the desired value. Limits are ignored for this element.

If the specified file cannot be found (status codes RMS$_FNF, RMS$_NMF, RMS$_DNF and RMS$_DEV) it is not considered an error. This eases the task of maintaining policies to cover multiple nodes.

• ALFPROHIB
• ALFREQUIRE
• ALSPROHIB
• ALSREQUIRE
• AUFPROHIB
• AUFREQUIRE
• AUSPROHIB
• AUSREQUIRE
• PERCENTLO
• PERCENTHI

Thus, each such exemption can be set once for each possible access type. If no selector is specified with the command interface, customization commands apply to all possible selector values.

Limits

Exemptions

There is not much point in establishing an exemption with a value of FALSE for one of the ACL-related constraints. 

Test the integrity of specified files.

Violation reports

Description

This element uses limits and exemptions in a different fashion than most. Each file to be tested must be specified in an exemption, where the value associated with the exemption is a string of hexadecimal characters representing the proper checksum value. The value associated with the limit can be used as an initialization vector for the checksum algorithm. No such use is made for the SHA1 or SIMPLE tests, so this capability is only meaningful for the SITE test.

If the specified file cannot be found (status codes RMS$_FNF, RMS$_NMF, RMS$_DNF and RMS$_DEV) it is not considered an error. This eases the task of maintaining policies to cover multiple nodes.

Test SIMPLE provides a very simple checksum routine which could be fooled by a skilled attacker who crafted their file modifications so as not to change the resulting checksum value.

Test SHA-1 provides a true cryptographic checksum, giving detection of not only inadvertent but also malicious manipulation of images by a skilled attacker. There is a price to be paid in execution time, however, since on a fast VAX running the SHA1 test across all images provided as part of VMS takes about 2 hours, while doing the same thing with the SIMPLE test takes about 2 minutes.

In special circumstances, some sites prefer to use a cryptographic checksum of their own design. Test SITE provides for a site-specified checksum algorithm.

For information on how to provide a site-specific checksum algorithm, refer to Section 9.2.3,LJK$SECURITY_SITE_CHECKSUM callback.

Limits

Exemptions

For sites which are interested in such a high level of security, the list of installed images is a good starting list, since they are declared "trusted" by installing them. For those images that come as part of VMS, command procedures to set a policy up are described in Appendix K, Creating Policies Based on Examples. Added to that list should be any other programs run by privileged users.

LJK Software makes no claims regarding the stability of executable images on a typical VMS system. In the past, some VMS images have undergone regular modification as a part of normal operation. In particular, this is true of the SYS.EXE image on VAX. 

Ensure that protections on all DEC DBMS files fall within the restrictions set by policy. DEC DBMS files in this context are all of those with the following file types:

• .ROO
• .DBS
• .AIJ

Violation reports

Description

DEC DBMS files are normally protected to allow only SYSTEM access, so that even the owner of the database must use DBMS access methods.

The ABSOLUTLO and ABSOLUTHI tests measure the UIC-based protection mask directly. The PERCENTLO and PERCENTHI tests measure the result of protection (including ACL protection) in terms of the percentage of usernames given access.

Violations for protection-related DISK facility elements are not reported regarding only the writeability of CDROM disks since the apparent writeability is just an illusion.

By default, a minimum of 0 percent of users must have access and a maximum of 1 percent of users may have READ, WRITE and CONTROL access, and a maximum of 0 percent of users may have other forms of access. Customizing DEC DBMS access is normally granted only through access control lists within the database, so there should be no need to customize the default limits for this element. selector Limits for constraints PERCENTLO and PERCENTHI can take a selector consisting of a VMS file access type: READ, WRITE, EXECUTE, DELETE or CONTROL. If no selector is specified, customization commands apply to all possible selector values.

Limits

Exemptions

Ensure that protections on all directories fall within the restrictions set by policy.

Violation reports

Description

If a directory's protection setting is not restrictive enough, unauthorized users will be able to read, write, execute, or delete the directory in question. If the setting is too restrictive, users generally find a less acceptable way of sharing information to get their job done. Typically, they share their password or make an unauthorized copy of the files within the directory somewhere else.

The purpose of this test is to ensure that directory protection settings are within the limits set by the security manager.

The ABSOLUTLO and ABSOLUTHI tests measure the UIC-based protection mask directly. The PERCENTLO and PERCENTHI tests measure the result of protection (including ACL protection) in terms of the percentage of usernames given access.

Violations for protection-related DISK facility elements are not reported regarding only the writeability of CDROM disks since the apparent writeability is just an illusion.

By default, a minimum of 0 percent of users must have access and a maximum of 10 percent of users may have READ, WRITE, DELETE and CONTROL access while a maximum of 100 percent may have EXECUTE access. Customizing Limits for constraints ABSOLUTLO and ABSOLUTHI take the same form as a standard VMS file protection setting. The syntax for this is explained in some detail in VMS documentation. The default settings shown in the limits table below are good examples of how to specify which class of users are allowed which type of access. These are the codes involved:

• S=System account (or users with the SYSPRV privilege)
• O=Owner of the file
• G=Group (i.e., other users in the same UIC group as the owner)
• W=World (i.e., all other users)

• R=Read
• W=Write
• E=Execute
• D=Delete

Limits

Exemptions

Ensure that specification of Erase On Delete for disk volumes conforms to local policy.

Violation reports

Description

When Erase On Delete is specified for a disk volume, all files deleted from that volume will have their disk space overwritten with a system-specified pattern.

Note that this is different from setting individual files to be erased on deletion.

Limits

Exemptions

Ensure that protections on files not covered by other file protection elements fall within the restrictions set by policy.

Violation reports

Description

If a file's protection setting is not restrictive enough, unauthorized users will be able to read, write, execute, or delete the file in question. If the setting is too restrictive, users generally find a less acceptable way of sharing information to get their job done. Typically, they share their password or make an unauthorized copy of the file somewhere else.

The purpose of this test is to ensure that file protection settings are within the limits set by the security manager.

---

Previous

Next

Contents

Index