| 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.Default policy Use of a DECnet default outgoing account is prohibited. Customizing Exemptions for this type of default DECnet account should be granted very unwillingly. This is a very old and very insecure mechanism. selector
| 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.Default policy Use of a DECnet default privileged account is prohibited. Customizing Exemptions may be in order if a particular application is using this sort of default DECnet account in a meaningful way. There are certain features of this account which can enhance security, but designs should be reviewed with an expert to look for alternative implementation methods. selector
| 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:Default policy Use of poor man's routing is prohibited. Customizing The need for poor man's routing went away with the introduction of DECnet Phase 3, so exemptions here do not seem a good idea. selector
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,
although some give different treatment to disks
and terminals (for which there are separate tests).
Exemptions are based on node name and device name.
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.Default policy Identifiers in ACLs must not be UIC identifiers. Customizing The options of prohibiting General and System identifiers are provided for flexibility, but are not useful in most circumstances. The main customization which might be desired is to remove the prohibition against the use of UIC identifiers. selectorThe 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.Default policy Every idle device must be owned by the system. Customizing An alternative owner can be specified for any device by setting an exemption. It is also possible to change the standard owner to be some account other than the system, by changing the limit for this test. selectorThe 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.Default policy The protection setting for each device must allow at least the system read, write, logical, and physical access. At most, it will allow all users read, write, logical, and physical 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.
By default, a minimum of 0 percent of users must have access and a maximum of 10 percent of users may have access. Customizing The default limit values for these tests leave device protection "wide open", so changes should be made to obtain any value from this test. selector Limits for constraints PERCENTLO and PERCENTHI can take a selector consisting of a VMS device access type: READ, WRITE, LOGICAL, PHYSICAL or CONTROL. If no selector is specified, customization commands apply to all possible selector values.
| 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.
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.Default policy Identifiers in ACLs must not be UIC identifiers. Customizing The options of prohibiting General and System identifiers are provided for flexibility, but are not useful in most circumstances. The main customization which might be desired is to remove the prohibition against the use of UIC identifiers. selectorThe 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 |