LJK/Security Reference Manual
DISRECON
Determine whether disabling of reconnection conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Reconnection is disabled in violation of policy
|
|
REQUIRED
|
Reconnection is not disabled in violation of policy
|
Description
Individual usernames can be prohibited from reconnecting to detached
processes. The ability to reconnect (provided by the VMS virtual
terminal
mechanism) is generally viewed as a continuity of service feature. In
cases where a single username might have multiple
interactive jobs at the same time, prohibiting reconnection might be
appropriate in order to avoid confusion.
Default policy Disabling of reconnection is neither prohibited nor
required. Customizing Setting limits in combination
with exemptions can be used to PROHIBIT or REQUIRE
reconnection capability for particular usernames. 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 If allowing reconnection would cause confusion
due to sharing of usernames
between individuals, it is that sharing which should be addressed. If
multiple individuals have identical access requirements, they can be
assigned separate usernames with identical characteristics (including
UIC) while preserving separate passwords and process accountability.
DISREPORT
Determine whether disabling reporting of last login conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Reporting last login is disabled in violation of policy
|
|
REQUIRED
|
Reporting last login is enabled in violation of policy
|
Description
Reporting of last login time is an important technique for detecting
unauthorized use of usernames (since only the authorized individual is
in a position to know the proper last login).
Default policy Disabling the reporting of last login is prohibited.
Customizing There is virtually no security-acceptable reason for
disabling this notification, but like all tests, the customization
capability is provided. 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 This notification is of no use unless end
users are trained to report suspicious incidents. Setting a false
"last login" value through
system programming can be used to test whether end users are in fact
going to report such incidents.
DISPWDSYNC
Determine whether password synchronization into VMS conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Password synchronization into VMS is enabled in violation of policy
|
|
REQUIRED
|
Password synchronization into VMS is disabled in violation of policy
|
Description
The DISPWDSYNC authorization flag indicates that the passwords used to
authenticate to non-VMS ACME agents should be stored by the VMS ACME
into SYSUAF for future use in VMS-only authentication.
Default policy Password synchronization is neither required nor
prohibited. Customizing Use these tests to match how
you use external authentication. 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 If you do not use external authentication,
ignore this element.
DISUSER
Determine whether disabling of username conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Username is disabled in violation of policy
|
|
REQUIRED
|
Username is not disabled in violation of policy
|
Description
The DISUSER flag applied to a username entry in the authorization file
prevents logins under the username.
Default policy Disabling of a username is neither prohibited nor
required. Customizing Customization here can be used to track usernames
as outlined in
Section 11.2, Tracking Usernames. 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 Rather than removing usernames from the
authorization file, many
system administrators prefer to set the DISUSER flag, so that any
attempts
against those usernames will include the username in the accounting
file.
If a username is not on the system at all, it is not included in the
accounting file record of a login failure.
DISWELCOME
Determine whether disabling welcome message conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Display of welcome message is disabled in violation of policy
|
|
REQUIRED
|
Display of welcome message is enabled in violation of policy
|
Description
Disabling the welcome message from being displayed to particular
usernames can be a security hazard if that message is typically used to
alert users to security-relevant information.
Default policy Disabling the welcome message is prohibited. Customizing
Disabling the Welcome message may be acceptable if is it not used for
security-relevant information. 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 Welcome message (received after successful
login) should not be confused with the Announce message (received just
before the username prompt).
Since the username is not known at the time the Announce message is
issued, there is no way to tailor the Announce message on a
per-username basis.
EXPIRATION
Determine whether expiration of username conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
RELATIVLO
|
Username expiration is too soon in violation of policy
|
|
RELATIVHI
|
Username expiration is too far away in violation of policy
|
Description
Usernames which have expiration dates very far in the future will
possibly escape periodic review by appropriate authorities to determine
if the usernames
are still needed.
Usernames which expire very soon are presumably overdue for management
review.
If such usernames are allowed to expire when they are still needed, the
result will be increased user hostility toward security concerns in
general.
Default policy Usernames must have a remaining lifetime between 30 and
1000 days. Customizing The default RELATIVLO limit
should be changed if you have a different need for warning about
expiring usernames. Exemptions are probably in order
for the SYSTEM username.
A limit or exemption with a value of zero means there is no value which
is considered unacceptable. selector
Limits
| Constraint |
Value |
Default |
|
RELATIVLO
|
0---n (days)
|
30
|
|
RELATIVHI
|
0---n (days)
|
1000
|
Exemptions
| Constraint |
Value |
Parameters |
|
RELATIVHI
|
0---n (days)
|
<node>, <username>
|
|
RELATIVLO
|
0---n (days)
|
<node>, <username>
|
Practical considerations Limited username lifetime will only be
acceptable if you provide timely
notification in advance of expiration to those who might care if a
username becomes unavailable.
EXTAUTH
Determine whether external authentication conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
External authentication is enabled in violation of policy
|
|
REQUIRED
|
External authentication is disabled in violation of policy
|
Description
The EXTAUTH authorization flag indicates that non-VMS ACME agents are
allowed to authenticate this user.
Default policy External authentication is neither required nor
prohibited. Customizing Use these tests to match how
you use external authentication. 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 If you do not use external authentication,
ignore this element.
GENPWD
Determine whether requirement for generated password conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
Generated password requirement is enabled in violation of policy
|
|
REQUIRED
|
Generated password requirement is disabled in violation of policy
|
Description
Requiring users to choose only generated passwords reduces the chances
that passwords can be guessed, but may increase the chance they will be
written down.
Default policy Requirement for generated passwords is prohibited.
Customizing Change the limits if your rule is to
require generated passwords. 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 Even if generated passwords are not required,
individual users are still free to ask for automatic password
generation as part of their periodic password changes.
GRPNAM
Determine whether a user with GRPNAM privilege shares a UIC group with
a more privileged user.
Violation reports
| Constraint |
Nature of the violation |
|
PRIVPROHIB
|
GRPNAM user shares a UIC group with more privileged users in violation
of policy
|
|
ABSOLUTHI
|
GRPNAM user shares a UIC group with more privileged users in violation
of policy
|
Description
The GRPNAM privilege allows a user to make group logical name table
entries which could affect other users in that group. In the case where
a more privileged user is in the same group, the actions of that user
could be subverted.
Default policy Users with GRPNAM privilege are forbidden to be in the
same group with more privileged users. Customizing Set
limit PROHIBITED to be FALSE to remove the prohibition
against users with GRPNAM privilege sharing UIC groups with more
privileged users. selector
Limits and exemptions for
test PRIVPROHIB can take a selector consisting of a
privilege name.
Thus, it can be set once for each possible privilege. When using the
Command Interface if you do not specify a selector when changing the
limit or exemptions your change
applies to all privileges.
Limits
| Constraint |
Value |
Default |
|
PRIVPROHIB
|
FALSE or TRUE
|
FALSE
|
|
ABSOLUTHI
|
Category-None---Category-All
|
Category-None
|
Exemptions
| Constraint |
Value |
Parameters |
|
PRIVPROHIB
|
FALSE or TRUE
|
<node>,<username>
|
|
ABSOLUTHI
|
Category-None---Category-All
|
<node>,<username>
|
Practical considerations Many historic reasons for needing the GRPNAM
privilege are no longer true.
The test ABSOLUTHI is sufficient to express simpler
limitations based on privilege level.
If a more complicated selection of privileges is required, it may be
necessary to use the test PRIVPROHIB.
GRPPRV
Determine whether a user with GRPPRV privilege shares a UIC group with
a more privileged user.
Violation reports
| Constraint |
Nature of the violation |
|
PRIVPROHIB
|
GRPPRV user shares a UIC group with more privileged users in violation
of policy
|
|
ABSOLUTHI
|
GRPPRV user shares a UIC group with more privileged users in violation
of policy
|
Description
The GRPPRV privilege allows a user to access files of other users in
the same UIC group. In the case where a more privileged user is in the
same group, the actions of that user could be subverted.
Default policy Users with GRPPRV privilege are forbidden to be in the
same group with more privileged users. Customizing Set
limit PROHIBITED to be FALSE to remove the prohibition
against users with GRPPRV privilege sharing UIC groups with more
privileged users. selector
Limits and exemptions for
test PRIVPROHIB can take a selector consisting of a
privilege name.
Thus, it can be set once for each possible privilege. When using the
Command Interface if you do not specify a selector when changing the
limit or exemptions your change
applies to all privileges.
Limits
| Constraint |
Value |
Default |
|
PRIVPROHIB
|
FALSE or TRUE
|
FALSE
|
|
ABSOLUTHI
|
Category-None---Category-All
|
Category-None
|
Exemptions
| Constraint |
Value |
Parameters |
|
PRIVPROHIB
|
FALSE or TRUE
|
<node>,<username>
|
|
ABSOLUTHI
|
Category-None---Category-All
|
<node>,<username>
|
Practical considerations The easiest approach to solving this problem
is probably to reduce the privileges of the more-privileged user.
The test ABSOLUTHI is sufficient to express simpler
limitations based on privilege level.
If a more complicated selection of privileges is required, it may be
necessary to use the test PRIVPROHIB.