| Previous | Contents | Index |
Determine whether presence of DECnet Default Outgoing Account conforms to policy.
| Constraint | Nature of the violation |
|---|---|
| PROHIBITED | DECnet Default Outgoing Account is present in violation of policy |
| REQUIRED | DECnet Default Outgoing Account is absent in violation of policy |
A DECnet default outgoing account is an older form of default DECnet account which involves storing a password for one node on another node. It is thus even less secure than the DECnet default incoming account, without providing the added features of the DECnet default privileged account.
| Constraint | Value | Default |
|---|---|---|
| PROHIBITED | FALSE or TRUE | TRUE |
| REQUIRED | FALSE or TRUE | FALSE |
| Constraint | Value | Parameters |
|---|---|---|
| PROHIBITED | FALSE or TRUE | <node> |
| REQUIRED | FALSE or TRUE | <node> |
Determine whether presence of DECnet Default Privileged Account conforms to policy.
| Constraint | Nature of the violation |
|---|---|
| PROHIBITED | DECnet Default Privileged Account is present in violation of policy |
| REQUIRED | DECnet Default Privileged Account is absent in violation of policy |
DECnet default privileged accounts are implemented by storing the password to one node on another node, and transmitting that password on behalf of the user if certain privileges are held. It is most often used for special-purpose applications or in system management.
| Constraint | Value | Default |
|---|---|---|
| PROHIBITED | FALSE or TRUE | TRUE |
| REQUIRED | FALSE or TRUE | FALSE |
| Constraint | Value | Parameters |
|---|---|---|
| PROHIBITED | FALSE or TRUE | <node> |
| REQUIRED | FALSE or TRUE | <node> |
Ensure that usage of FAL routing conforms to local policy.
| Constraint | Nature of the violation |
|---|---|
| PROHIBITED | FAL Poor Man's Routing is enabled in violation of policy |
| REQUIRED | FAL Poor Man's Routing is disabled in violation of policy |
Poor man's routing through FAL is used when a user provides multiple node specifications in a filespec, such as:
It can be used to circumvent normal access paths in some situations.
NODE1::NODE2::DISK$USER:[SMITH]FINANCE.DATIf the DECnet FAL object finds logical name FAL$LOG to contain the substring "/DISABLE=8", poor man's routing will be prevented.
| Constraint | Value | Default |
|---|---|---|
| PROHIBITED | FALSE or TRUE | TRUE |
| REQUIRED | FALSE or TRUE | FALSE |
| Constraint | Value | Parameters |
|---|---|---|
| PROHIBITED | FALSE or TRUE | <node> |
| REQUIRED | FALSE or TRUE | <node> |
The logical name FAL$LOG is interpreted in the context of each FAL server process, and there is no requirement that logical names be in executive mode, so an individual user can override the FAL$LOG value specified on a system-wide basis. This mechanism is useful, however, for accounts where a user does not have interactive access or the ability to define logical names.
This feature of FAL$LOG is not documented and supported by VMS Development. Although VMS Development has gone to some trouble to implement it, they reserve the right to change or remove the feature at any time.
6.4 DEVICE tests
Tests in the DEVICE facility deal with all devices
other than disks
and terminals (for which there are separate tests).
Exemptions are based on node name and device name.
The node name in an exemption for the DEVICE facility can include standard VMS wildcard characters (% and *).
The device name in an exemption for the DEVICE facility can include standard VMS wildcard characters (% and *), or can specify a system logical name which at assessment time resolves to the device to be exempted. This allows for the case where a system component creates a mailbox like "ACME$MAILBOX" which might get a different mailbox number on different systems or on different boots of the same system but which deserves a particular exemption in all cases.
Ensure that identifier types used in access control lists conform to policy.
| Constraint | Nature of the violation |
|---|---|
| NOGENERAL | General identifier used in violation of policy |
| NOSYSTEM | System-defined identifier used in violation of policy |
| NOUIC | UIC identifier used in violation of policy |
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.
| Constraint | Value | Default |
|---|---|---|
| NOGENERAL | FALSE or TRUE | FALSE |
| NOSYSTEM | FALSE or TRUE | FALSE |
| NOUIC | FALSE or TRUE | TRUE |
| Constraint | Value | Parameters |
|---|---|---|
| NOGENERAL | FALSE or TRUE | <node>, <device-name> |
| NOSYSTEM | FALSE or TRUE | <node>, <device-name> |
| NOUIC | FALSE or TRUE | <node>, <device-name> |
Ensure that ownership of devices is retained by the system and not by an individual user, except when the device is in use.
| Constraint | Nature of the violation |
|---|---|
| WRONG | Device owner is not as specified |
If an individual user account gains ownership of a device, it also gains access to any information that is stored on it or transmitted through it. A particular concern is the case of terminal ports, in which this ownership would allow one user to read another user's password as it is typed. Another concern is that other users would be unable to use a device owned by an individual user, even when the ownership is acquired inadvertently.The purpose of this test is to ensure that the system retains ownership of devices that are not in use. This test checks the ownership of any device not currently in use and reports any instance in which the owner is not the system.
For limits only (not exemptions), owner matching string of [SYSTEM] will match (as a special case) against UIC's which are represented as [1,4] (due, for instance, to absence of a Rights Database (RIGHTSLIST.DAT)).
| Constraint | Value | Default |
|---|---|---|
| WRONG | Identifier | [SYSTEM] |
| Constraint | Value | Parameters |
|---|---|---|
| WRONG | Identifier | <node>, <device-name> |
Ensure that each device's protection setting meets the minimum setting defined by policy.
| Constraint | Nature of the violation |
|---|---|
| ABSOLUTLO | Access is narrower than permitted by policy |
| ABSOLUTHI | Access is wider than permitted by policy |
| PERCENTLO | Fewer users can access than permitted by policy |
| PERCENTHI | More users can access than permitted by policy |
Under VMS, a protection setting can be applied to a device in the same way that it can be applied to files. This allows a given user (or group of users) to have exclusive access to a given disk, for example. Conversely, it can be set to keep a device open for access by all users, or to limit them to read access.The purpose of this test is to ensure that the protection settings for devices remain at the levels established by policy.
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 (ignoring usernames that have been disabled).
By default, a minimum of 0 percent of users must have access and a maximum of 10 percent of users may have access
| Constraint | Value | Default |
|---|---|---|
| ABSOLUTLO | Any Protection | (S,O:RWPL,G,W) |
| ABSOLUTHI | Any Protection | (S:RWPL,O:RWPL,G:RWPL,W:RWPL) |
| PERCENTLO | 0-100 | 0 |
| PERCENTHI | 0-100 | 10 |
| Constraint | Value | Parameters |
|---|---|---|
| ABSOLUTLO | Any Protection | <node>, <device-name> |
| ABSOLUTHI | Any Protection | <node>, <device-name> |
| PERCENTLO | 0-100 | <node>, <device-name> |
| PERCENTHI | 0-100 | <node>, <device-name> |
6.5 DISK Tests
Tests in the DISK facility deal with overall disk
volume security and individual file security.
Exemptions are based on node name and volume name or file specification.
Disk served by the Distributed File Service product from HP (DECdfs) will not be tested on the client machine, but only on the serving machine. This is different from the approach taken with MSCP served disks in a cluster, because in the cluster situation a common security domain is present and testing file ownership and protection is meaningful. In the DFS case, all access is via proxy logins, so testing file ownership and protection can only be done from the serving machine.
In cases where a violation is detected on a file which happens to be the target of alias directory entries, the violation is reported only for the main file specification.
The following elements are tested in concert:
The FILEPROT element covers files which do not fit one of the other categories.
In the case of CD-ROM disks, the ABSOLUTLO, ABSOLUTHI and PERCENTHI constraints are tested with compensation for the fact that the disk cannot be written. In the case of the PERCENTLO constraint, however, no such compensation is made, so there will be violations reported if access percentages (for Write and Delete) calculated from nominal file protections are less than specified in the policy, even though a different setting would not change the actual protection of the CD-ROM files. This approach is taken to avoid a situation where two tests would provide conflicting reports as to the percentage of users with Write or Delete access.
That general approach to exhaustive disk file scanning is to hold files of similar nature to the same standard, adding exemptions for files allowed to exceed that standard. If you have particular files you want held to a tighter standard than others, designate them in exemptions for the CHECKPROT constraints. The CHECKPROT and CHECKSUM elements perform no processing based on the limits, but instead exclusively test files that are indicated for exemptions for their constraints.
The node name in an exemption for the DISK facility can include standard VMS wildcard characters (% and *).
The volume name or file specification in an exemption for the DISK facility can include standard VMS wildcard characters (% and *).
Ensure that identifier types used in access control lists conform to policy.
| Constraint | Nature of the violation |
|---|---|
| NOGENERAL | General identifier used in violation of policy |
| NOSYSTEM | System-defined identifier used in violation of policy |
| NOUIC | UIC identifier used in violation of policy |
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.
| Constraint | Value | Default |
|---|---|---|
| NOGENERAL | FALSE or TRUE | FALSE |
| NOSYSTEM | FALSE or TRUE | FALSE |
| NOUIC | FALSE or TRUE | TRUE |
| Constraint | Value | Parameters |
|---|---|---|
| NOGENERAL | FALSE or TRUE | <node>, <device-name> or <filespec> |
| NOSYSTEM | FALSE or TRUE | <node>, <device-name> or <filespec> |
| NOUIC | FALSE or TRUE | <node>, <device-name> or <filespec> |
| Previous | Next | Contents | Index |