LJK/Security Reference Manual
OWNER
Ensure that ownership of terminals is retained by the system and not by
an individual user, except when the terminal is in use.
Violation reports
| Constraint |
Nature of the violation |
|
WRONG
|
Terminal owner is not the system
|
Description
If an individual user account gains ownership of a terminal, it also
gains access to any information that is stored on it or transmitted
through it. A particular concern in the case of terminal ports,
is that ownership would allow one user to read another user's password
as it is typed.
The purpose of this test is to ensure that the system retains ownership
of terminals that are not in use. This test checks the ownership of any
terminal 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).
Default policy By default, every idle terminal must be owned by the
system. Customizing An alternative owner can be specified for any
terminal 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. selector Limits
| Constraint |
Value |
Default |
|
WRONG
|
Identifier
|
[SYSTEM]
|
Exemptions
| Constraint |
Value |
Parameters |
|
WRONG
|
Identifier
|
<node>, <device-name>
|
Practical considerations Device ownership and protection must be
considered jointly.
PROTECTION
Determine whether terminal protection conforms to policy.
Violation reports
| 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
|
Description
Unprotected terminals can be used by an attacker as part of a password
grabbing scheme. Terminals which are used for logins should be protected
against all but SYSTEM access. In the process of logging in, access for
the logged-in user is established independent of the terminal
protection, so allowing only SYSTEM access via the terminal protection
mask does not
interfere with authorized logins.
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.
Default policy Access is allowed only to SYSTEM.
By default, a minimum of 0 percent of users must have access and a
maximum of 1 percent of users may have access. Customizing Exemptions
will be required for dial-out lines or other lines not used
for interactive login.
Note
The same line should never be used for both dial-out and
dial-in,
due to the simplicity of mounting a password grabber attack.
|
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.
Limits
| Constraint |
Value |
Default |
|
ABSOLUTLO
|
Any Protection
|
(S:RWPL,O:RWPL,G,W)
|
|
ABSOLUTHI
|
Any Protection
|
(S:RWPL,O:RWPL,G,W)
|
|
PERCENTLO
|
0-100
|
0
|
|
PERCENTHI
|
0-100
|
1
|
Exemptions
| 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>
|
Practical considerations Older VMS systems may have weaker protections
established long ago. The reasons for those settings are generally no
longer valid.
SECURE
Determine whether specification of secure server conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Secure server is enabled in violation of policy
|
|
REQUIRED
|
Secure server is disabled in violation of policy
|
Description
The secure server feature of VMS provides defense for non-dialup users
(particularly in public terminal rooms) from password grabbers left
running
on terminals creating the illusion that a terminal is vacant.
Default policy Specification of secure server is neither prohibited nor
required. Customizing Requirements for this feature on a node-by-node
basis can be checked by setting both limits TRUE and
using wildcard exemption arguments. selector
Limits
| Constraint |
Value |
Default |
|
PROHIBITED
|
FALSE or TRUE
|
FALSE
|
|
REQUIRED
|
FALSE or TRUE
|
FALSE
|
Exemptions
| Constraint |
Value |
Parameters |
|
PROHIBITED
|
FALSE or TRUE
|
<node>, <device-name>
|
|
REQUIRED
|
FALSE or TRUE
|
<node>, <device-name>
|
Practical considerations This feature is useful only if pervasive, so
that users understand that the break key must be used in all
cases.
SYSPWD
Determine whether requirement for system password conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
System password is enabled in violation of policy
|
|
REQUIRED
|
System password is disabled in violation of policy
|
Description
The system password is an additional password which must be entered
before the Username prompt is provided by VMS.
Default policy Provision of a system password is prohibited, favoring
instead the non-sharing of passwords.
Customizing Switch the limits if your organizational
policy is to have shared system passwords for initial access.
selector Limits
| Constraint |
Value |
Default |
|
PROHIBITED
|
FALSE or TRUE
|
TRUE
|
|
REQUIRED
|
FALSE or TRUE
|
FALSE
|
Exemptions
| Constraint |
Value |
Parameters |
|
PROHIBITED
|
FALSE or TRUE
|
<node>, <device-name>
|
|
REQUIRED
|
FALSE or TRUE
|
<node>, <device-name>
|
Practical considerations The prime use of the system password mechanism
is to defend against total outsiders. Even with different system
passwords for various nodes, knowledge
of the proper password spreads very quickly within an organization.
TYPEAHEAD
Determine whether enable state for the typeahead buffer conforms to
policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Typeahead buffer is enabled in violation of policy
|
|
REQUIRED
|
Typeahead buffer is disabled in violation of policy
|
Description
A terminal which has the typeahead buffer disabled cannot be used for
login. This is useful for protecting outgoing modem lines.
These tests are intended to allow reporting when permanent terminal
characteristics do not conform to policy.
Default policy Enabling of the typeahead buffer is neither prohibited
nor required. Customizing You can set limits to indicate a general
policy, and exemptions on an individual basis. selector Limits
| Constraint |
Value |
Default |
|
PROHIBITED
|
FALSE or TRUE
|
FALSE
|
|
REQUIRED
|
FALSE or TRUE
|
FALSE
|
Exemptions
| Constraint |
Value |
Parameters |
|
PROHIBITED
|
FALSE or TRUE
|
<node>, <device-name>
|
|
REQUIRED
|
FALSE or TRUE
|
<node>, <device-name>
|
Practical considerations Some sites with little terminal use may choose
to prohibit typeahead buffers in the limit and then
permit them in exemptions for certain terminals.
6.7 UAF Tests
Tests in the UAF facility
1
are associated with individual user authorization and authentication
information, such as passwords, privileges
and similar characteristics.
Exemptions are based on node name and
username.
Note
In the test descriptions for this facility, unlike the rest of the
manual, the term "user" refers to an end user rather than a
security
administrator.
|
Note
1 The term UAF stands for "User
Authorization File", the main repository of user identification,
authentication, authorization and
initialization information in VMS. The actual filename is
SYSUAF.
|
AUDIT
Determine whether the presence or absence of a requirement to audit all
authorization activity conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Auditing is enabled in violation of policy
|
|
REQUIRED
|
Auditing is disabled in violation of policy
|
Description
Enabling this per-user auditing flag will cause all
authorization-related
activities to be sent to the VMS audit trail.
Default policy Auditing all authorization activity is neither
prohibited nor required. Customizing An aggressive auditing program
would mandate changes here. Someone, however, will have to scan the
audit logs unless the data is just being kept for
historical purposes. selector Limits
| Constraint |
Value |
Default |
|
PROHIBITED
|
FALSE or TRUE
|
FALSE
|
|
REQUIRED
|
FALSE or TRUE
|
FALSE
|
Exemptions
| Constraint |
Value |
Parameters |
|
PROHIBITED
|
FALSE or TRUE
|
<node>, <username>
|
|
REQUIRED
|
FALSE or TRUE
|
<node>, <username>
|
Practical considerations Older versions of VMS (at least through V5.0)
do not distinguish between
data which is being audited for historical purposes and that which is
of immediate interest to those with terminals enabled for security
alarm messages.
The result of excessive auditing can be to have all such messages
ignored.
AUTOLOGIN
Determine whether designation as autologin-only conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Autologin-only is enabled in violation of policy
|
|
REQUIRED
|
Autologin-only is disabled in violation of policy
|
Description
Enabling autologin-only status for a username provides protection
against misuse of an autologin account. Use of the autologin feature of
VMS, however, can serve to weaken security.
Default policy Designation as autologin-only is prohibited. Customizing
Exemptions are in order if autologin is used, but it
is best to retain the PROHIBITED limit to ensure that
new instances of autologin usage
are detected. selector Limits
| Constraint |
Value |
Default |
|
PROHIBITED
|
FALSE or TRUE
|
TRUE
|
|
REQUIRED
|
FALSE or TRUE
|
FALSE
|
Exemptions
| Constraint |
Value |
Parameters |
|
PROHIBITED
|
FALSE or TRUE
|
<node>, <username>
|
|
REQUIRED
|
FALSE or TRUE
|
<node>, <username>
|
Practical considerations It is best to keep careful track of cases
where autologin is used, since it is not a widely-known feature of VMS
and might get improperly maintained if a new administrator is assigned
who is unfamiliar with it (or does not
realize it is used on a particular node).
CAPTIVE
Determine whether designation as captive account conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Captive flag is enabled in violation of policy
|
|
REQUIRED
|
Captive flag is disabled in violation of policy
|
Description
The captive flag prevents a user from avoiding a login command procedure
by disabling some techniques commonly used to escape such procedures.
Effective with VMS Version 5.2, the Captive authorization flag assumed
a stronger meaning and the Restricted authorization flag was created to
cover the older weaker meaning (without automatic logout if the user
ever got to DCL).
Default policy Designation as a captive account is neither prohibited
nor required. Customizing In some organizations all accounts are set
captive to ensure completion of mandatory login command procedure code.
If this is the case, setting the REQUIRED limit is in
order. selector Limits
| Constraint |
Value |
Default |
|
PROHIBITED
|
FALSE or TRUE
|
FALSE
|
|
REQUIRED
|
FALSE or TRUE
|
FALSE
|
Exemptions
| Constraint |
Value |
Parameters |
|
PROHIBITED
|
FALSE or TRUE
|
<node>, <username>
|
|
REQUIRED
|
FALSE or TRUE
|
<node>, <username>
|
Practical considerations The CAPTIVE status is generally easier to
understand than the collection of individual limiting flags it
encompasses.
CLIDCL
Determine whether specification of DCL as command language conforms to
policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Default CLI is DCL in violation of policy
|
|
REQUIRED
|
Default CLI is not DCL in violation of policy
|
Description
DCL (Digital Command Language) is generally the language for which
login command procedures have been written. If alternate command
languages are
used, equivalent login command procedures must be provided in order to
force execution of particular functions on login.
Default policy Default CLI of DCL is required. Customizing
Customization will be required if you make use of the MCR or DEC/Shell
command language interpreters, or any custom written CLI. selector
Limits
| Constraint |
Value |
Default |
|
PROHIBITED
|
FALSE or TRUE
|
FALSE
|
|
REQUIRED
|
FALSE or TRUE
|
TRUE
|
Exemptions
| Constraint |
Value |
Parameters |
|
PROHIBITED
|
FALSE or TRUE
|
<node>, <username>
|
|
REQUIRED
|
FALSE or TRUE
|
<node>, <username>
|
Practical considerations The procedure for writing a custom command
language interpreter is not
documented by DEC, so it is unlikely your organization has implemented
one.
CLIMCR
Determine whether specification of MCR as command language conforms to
policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Default CLI is MCR in violation of policy
|
|
REQUIRED
|
Default CLI is not MCR in violation of policy
|
Description
DCL (Digital Command Language) is generally the language for which
login command procedures have been written. If alternate command
languages are
used, equivalent login command procedures must be provided in order to
force execution of particular functions on login.
Default policy Default CLI of MCR is prohibited. Customizing
Customization will be required if you make use of the MCR command
language interpreters. selector Limits
| Constraint |
Value |
Default |
|
PROHIBITED
|
FALSE or TRUE
|
TRUE
|
|
REQUIRED
|
FALSE or TRUE
|
FALSE
|
Exemptions
| Constraint |
Value |
Parameters |
|
PROHIBITED
|
FALSE or TRUE
|
<node>, <username>
|
|
REQUIRED
|
FALSE or TRUE
|
<node>, <username>
|
Practical considerations The MCR command language interpreter is used
for RSX11 compatibility mode. It is not required for use of
the DCL command MCR to issue
foreign commands to programs.
CLIOTHER
Determine whether specification of something other than DCL, MCR or
DECshell as command language conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Default CLI is other than DCL, MCR or DEC/Shell in violation of policy
|
|
REQUIRED
|
Default CLI is DCL, MCR or DEC/Shell in violation of policy
|
Description
DCL (Digital Command Language) is generally the language for which
login command procedures have been written. If alternate command
languages are
used, equivalent login command procedures must be provided in order to
force execution of particular functions on login.
Default policy Default CLI other than DCL, MCR or DEC/Shell is
prohibited. Customizing Customization will be required if you make use
of any custom written CLI. selector Limits
| Constraint |
Value |
Default |
|
PROHIBITED
|
FALSE or TRUE
|
TRUE
|
|
REQUIRED
|
FALSE or TRUE
|
FALSE
|
Exemptions
| Constraint |
Value |
Parameters |
|
PROHIBITED
|
FALSE or TRUE
|
<node>, <username>
|
|
REQUIRED
|
FALSE or TRUE
|
<node>, <username>
|
Practical considerations The procedure for writing a custom command
language interpreter is not
documented by DEC, so it is unlikely your organization has implemented
one.
CLISHELL
Determine whether specification of DEC/Shell as command language
conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Default CLI is SHELL in violation of policy
|
|
REQUIRED
|
Default CLI is other than SHELL in violation of policy
|
Description
DCL (Digital Command Language) is generally the language for which
login command procedures have been written. If alternate command
languages are
used, equivalent login command procedures must be provided in order to
force execution of particular functions on login.
Default policy Default CLI of DEC/Shell is prohibited. Customizing
Customization will be required if you make use of the DEC/Shell command
language interpreter. selector Limits
| Constraint |
Value |
Default |
|
PROHIBITED
|
FALSE or TRUE
|
TRUE
|
|
REQUIRED
|
FALSE or TRUE
|
FALSE
|
Exemptions
| Constraint |
Value |
Parameters |
|
PROHIBITED
|
FALSE or TRUE
|
<node>, <username>
|
|
REQUIRED
|
FALSE or TRUE
|
<node>, <username>
|
Practical considerations The DEC/Shell command language interpreter is
also provided as part of the VNXset combination product from DEC.
DAYMUSTBE
Determine whether designation of primary and secondary days conforms to
policy.
Violation reports
| Constraint |
Nature of the violation |
|
PRIMARY
|
Failure to designate day PRIMARY violates policy
|
|
SECONDARY
|
Failure to designate day SECONDARY violates policy
|
Description
The concepts of Primary and Secondary days are defined on a
per-username basis, so if a uniform meaning for these terms is
required, these tests should be applied to detect deviations.
Default policy Monday through Friday must be primary days while
Saturday and Sunday must be secondary days. Customizing Customization
is required only if you want to allow specific deviation from the
default designations. In most cases it would be sufficient to establish
HOURSPRI and HOURSSEC limits and
exemptions as being the same. selector
Limits for this test can take a
selector consisting of the name of a day of the week.