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 as specified
|
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
(RIGHTSLIST.DAT)).
Default policy 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.8 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.
|
ACCESS
Ensure restrictions based on login type conform to policy.
Violation reports
| Constraint |
Nature of the violation |
|
AUDIT
|
Access for a particular login type is allowed without auditing all
activity
|
|
PROHIBITED
|
Access for a particular login type is allowed in violation of policy
|
|
REQUIRED
|
Access for a particular login type is forbidden in violation of policy
|
Description
The tests for the PROHIBITED and REQUIRED
constraints determine whether username access for
particular login types conform to policy.
The tests for the AUDIT constraints
determine whether the setting to audit all activity by usernames
allowed access for particular login types conforms to policy.
Default policy Access for particular login types is neither required no
forbidden and total auditing for particular login types is not
required. Customizing With considerable overhead it is possible to
audit all security actions of particular usernames.
With less overhead, it is possible to deny all but exempted usernames
access via particular login types. selector
Limits
| Constraint |
Value |
Default |
|
AUDIT
|
FALSE or TRUE
|
FALSE
|
|
PROHIBITED
|
FALSE or TRUE
|
FALSE
|
|
REQUIRED
|
FALSE or TRUE
|
FALSE
|
Exemptions
| Constraint |
Value |
Parameters |
|
AUDIT
|
FALSE or TRUE
|
<node>, <username>
|
|
PROHIBITED
|
FALSE or TRUE
|
<node>, <username>
|
|
REQUIRED
|
FALSE or TRUE
|
<node>, <username>
|
Practical considerations The tests in thie
element provide a check on certain security-relevant
combinations of settings in Username records within SYSUAF.
AUDIT
Determine whether the presence or absence of a requirement to audit all
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
The tests for the PROHIBITED and REQUIRED
constraints determine whether username access for
particular login types conform to policy.
The tests for the AUDIT constraints
determine whether the setting to audit all activity by usernames
conforms to policy.
Default policy Auditing all activity is neither prohibited nor
required. Customizing One possibility is to require auditing for all
usernames and then exempt particular usernames to reduce overhead.
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 Auditing all security actions uses lots of
resources.
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.