LJK/Security Reference Manual
SYSTEMLGI
Ensure that ability to log into the SYSTEM account conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
allowed in violation of policy
|
|
REQUIRED
|
prevented in violation of policy
|
Description
For reasons of accountability it is generally best to allow username
SYSTEM to log in only via Batch. System administrative tasks are then
performed in privileged accounts which can be traced to individuals.
Default policy Username SYSTEM is required to be able to log in for
batch and prohibited all other login methods. Customizing
Exemptions for individual nodes are generally better
than an organization-wide relaxation of limits, so
that over time nodes can be converted back one-by-one. selector
Limits for this test can take a
selector consisting of a login type: LOCAL, DIALUP,
REMOTE, NETWORK or BATCH.
Thus, each can be set once for each possible login type. If you do not
specify a selector when changing
limits, your change applies to all login types.
Note
The availability of separate selector values for LOCAL
and DIALUP should not be taken as a suggestion that the DIALUP
indication associated with terminals be trusted to accurately represent
whether or not a dialup line is actually in use. It is provided,
however, for sites which use the DIALUP indication to denote some
aspect of a terminal which can be determined with certainty,
such as whether or not a given terminal connection is via an X.25
circuit.
|
Limits
| Constraint |
Value |
Default |
|
PROHIBITED
|
FALSE or TRUE
|
TRUE*
|
|
REQUIRED
|
FALSE or TRUE
|
FALSE*
|
* except for BATCH selection.
Exemptions
| Constraint |
Value |
Parameters |
|
PROHIBITED
|
FALSE or TRUE
|
<node>
|
|
REQUIRED
|
FALSE or TRUE
|
<node>
|
Practical considerations In certain failure modes, such as the absence
of an authorization file or a denial-of-service attack via breakin
evasion, the username SYSTEM is uniquely allowed to log in from the
system console. This special capability of username SYSTEM indicates it
should be available to system managers, while general accountability
goals indicate that system managers should each use their own separate
usernames.
The best resolution of this conundrum is to implement the equivalent of
a "break the glass" fire alarm, with a generated password for
the SYSTEM username stored inside a tamper-evident container physically
bolted inside the protected computer room. Covering such a container
with video surveillance would be ideal.
SYSUAF
Determine the location of the user authorization file.
Violation reports
| Constraint |
Nature of the violation |
|
LOCATION
|
File is in an improper location
|
Description
Putting the system authorization file in a non-default location can be
a valuable administrative tool, particularly in clusters. If this is
done in an uncoordinated fashion, however, authorization changes might
be made to the wrong file.
Default policy The default location is SYS$COMMON:[SYSEXE]SYSUAF.DAT;,
which is the
VMS default. Customizing Since alternate locations will be on a
system-specific basis, you should leave the limit at its default value
and use per-system exemptions to permit deviations. The expression of
values should be phrased based on canonical mount logical names if the
files are not in SYS$COMMON.
A limit or exemption with a value of the null string means there is no
value which is considered unacceptable. selector
Limits
| Constraint |
Value |
Default |
|
LOCATION
|
Any filespec
|
SYS$COMMON:[SYSEXE]SYSUAF.DAT;
|
Exemptions
| Constraint |
Value |
Parameters |
|
LOCATION
|
Any filespec
|
<node>
|
Practical considerations If particular systems have varying locations
for the authorization file, you can nullify this test through the use
of wildcards in the value.
Note that system parameter ALTUAF can be used to affect the filespec
which
is used.
TIME
See if the relative times of master and
tributary nodes conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
OFFSET
|
Time offset between tributary and master node does not conform to policy
|
Description
The test within this element
determines whether the time offset between the master
and tributary nodes conforms to policy.
Default policy Time offset must be less than 15 seconds. Customizing A
common use is to check synchronization between tributary
nodes covered by a single assessment. The
fact that the comparison is against the master node is
just an artifact of implementation. selector Limits
| Constraint |
Value |
Default |
|
OFFSET
|
signed offset with deviation
|
-0-00:00:00.00+-0-00:00:15.00
|
Exemptions
| Constraint |
Value |
Parameters |
|
OFFSET
|
signed offset with deviation
|
<node>
|
Practical considerations The value for the OFFSET
constraint may require periodic adjustment if some of
the tributary nodes change their times due to Daylight
Savings Time, British Summer Time and the like.
TIMEPROMPT
Determine interval VMS will delay on boot for time to be entered.
Violation reports
| Constraint |
Nature of the violation |
|
ABSOLUTLO
|
System parameter TIMEPROMPTWAIT is lower than allowed by policy
|
|
ABSOLUTHI
|
System parameter TIMEPROMPTWAIT is higher than allowed by policy
|
Description
If system parameter SETTIME is 1, VMS will prompt for the time on each
boot.
The length of time VMS will wait for time to be input is set by system
parameter TIMEPROMPTWAIT, which is monitored by these tests. (These
tests are not
performed, however, if system parameter SETTIME is 0).
Values for TIMEPROMPTWAIT from 1 to 32768 specify that a single prompt
should be issued with a wait of the specified number of seconds. After
that wait, if no response has been received, the system boots using the
time of the last system boot.
Values from 32768 through 65535 indicate that prompting is to be
repeated indefinitely until a response is given.
The VMS parameter TIMEPROMPTWAIT has no effect if there is a
time-of-year clock containing a valid time when the system is booted.
Default policy The default limits are both set to the VMS default value
for system parameter TIMEPROMPTWAIT. Customizing If you have VMS
systems which have system parameter SETTIME set to 1, and have
a non-standard interval specified in system parameter TIMEPROMPTWAIT,
you will have to alter these limits or establish exemptions for the
affected nodes.
A limit or exemption with a value of zero means there is no value which
is considered unacceptable. selector
Limits
| Constraint |
Value |
Default |
|
ABSOLUTLO
|
0---n
|
65535
|
|
ABSOLUTHI
|
0---n
|
65535
|
Exemptions
| Constraint |
Value |
Parameters |
|
ABSOLUTLO
|
0---n
|
<node>
|
|
ABSOLUTHI
|
0---n
|
<node>
|
Practical considerations Except for the MicroVAX I and the VAX 11/730,
VAX processors have built-in
time-of-year clocks. With a clock, test (VMS, SETTIME, PROHIBITED) can
be set to TRUE, and this test can be ignored.
While an overly long delay on boot is a threat to continuity of service,
running with the software clock incorrectly set can lead to improper
application operation, also an undesirable condition.
TRIBUTARY
Ensure an appropriate number of tributary nodes are
tested in this assessment.
Violation reports
| Constraint |
Nature of the violation |
|
PERCENTLO
|
Fewer nodes in the assessment than permitted by policy
|
|
PERCENTHI
|
More nodes in the assessment than permitted by policy
|
Description
These tests measure against requirements that security
assessment be centralized.
Default policy There is no requirement for a particular number of
tributary nodes. Customizing These tests are primarily
of interest to sites which have a requirement that security assessment
be centralized. selector Limits
| Constraint |
Value |
Default |
|
PERCENTLO
|
0-100
|
0
|
|
PERCENTHI
|
0-100
|
100
|
Exemptions
| Constraint |
Value |
Parameters |
|
PERCENTLO
|
0-100
|
<node>, <device-name>
|
|
PERCENTHI
|
0-100
|
<node>, <device-name>
|
Practical considerations These tests are not helpful
on specialized assessments done to investigate particular
tributaries.
TTYTIMEOUT
See if the value of the TTY_TIMEOUT parameter conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
ABSOLUTHI
|
Interval for terminating a detached terminal process is higher than
allowed by policy
|
|
ABSOLUTLO
|
Interval for terminating a detached terminal process is lower than
allowed by policy
|
Description
The tests within this element
determine whether the value of the TTY_TIMEOUT parameter conforms to
policy.
Default policy TTY_TIMEOUT must specify between 15 and 60 minutes.
Customizing Wider range for TTY_TIMEOUT is rarely required. selector
Limits
| Constraint |
Value |
Default |
|
ABSOLUTHI
|
0-n
|
3600
|
|
ABSOLUTLO
|
0-n
|
900
|
Exemptions
| Constraint |
Value |
Parameters |
|
ABSOLUTHI
|
0-n
|
<node>
|
|
ABSOLUTLO
|
0-n
|
<node>
|
Practical considerations The MATCH constraint is
equivalent to including the same text in both the CONTAINED
constraint and the MATCH constraint.
Comparison treats line-feed, carriage-return, line-feed and form-feed
as equivalent to space. It also treats multiple spaces as equivalent to
a single space and artifically inserts a space before and after any
punctuation characters.
UAFALT
Determine whether VMS looks for SYSUAF in an alternate location.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
System parameter UAFALT is 1 in violation of policy
|
|
REQUIRED
|
System parameter UAFALT is 0 in violation of policy
|
Description
If system parameter UAFALT is 1, VMS will define a logical name
to specify that SYSUAF has an alternate name.
Default policy The setting of UAFALT is immaterial. Customizing
LJK Software recommends that skip these tests and
instead use the (VMS,SYSUAF,*) tests. selector
Limits
| Constraint |
Value |
Default |
|
PROHIBITED
|
FALSE or TRUE
|
FALSE
|
|
REQUIRED
|
FALSE or TRUE
|
FALSE
|
Exemptions
| Constraint |
Value |
Parameters |
|
PROHIBITED
|
FALSE or TRUE
|
<node>
|
|
REQUIRED
|
FALSE or TRUE
|
<node>
|
Practical considerations Detecting the setting of UAFALT is less
thorough than the (VMS,SYSUAF,*) tests.
VERSION
See if the VMS Version conforms to policy.
Violation reports
| Constraint |
Nature of the violation |
|
MATCH
|
VMS Version does not match that specified by policy
|
|
MAXIMUM
|
VMS Version is higher than allowed by policy
|
|
MINIMUM
|
VMS Version is lower than allowed by policy
|
Description
The tests within this element
determine whether the VMS Version of the tributary
node conforms to policy.
Default policy There are no requirements. Customizing Use the
constraints MAXIMUM and MINIMUM to check
organizational requirements for particular VMS versions. selector
Limits
| Constraint |
Value |
Default |
|
MATCH
|
0-8 characters
|
null string
|
|
MAXIMUM
|
0-8 characters
|
null string
|
|
MINIMUM
|
0-8 characters
|
null string
|
Exemptions
| Constraint |
Value |
Parameters |
|
MATCH
|
0-8 characters
|
<node>
|
|
MAXIMUM
|
0-8 characters
|
<node>
|
|
MINIMUM
|
0-8 characters
|
<node>
|
Practical considerations The command procedures described in
Section K.1.4, Exemptions for the VMS Trusted Computing Base may use the MATCH constraint to ensure
the values they specify for tests
from the (DISK, CHECKSUM) element are those for the
proper version of VMS.
WELCOME
See if the contents of the SYS$WELCOME message conform to policy.
Violation reports
| Constraint |
Nature of the violation |
|
CONTAINED
|
SYS$WELCOME message must be contained within the specified text
|
|
CONTAINS
|
SYS$WELCOME message must contain the specified text
|
|
MATCH
|
SYS$WELCOME message must match the specified text
|
Description
Compare the value of SYS$WELCOME (or the file to which it points) to
the specified policy text. If the logical name points to a file that is
not world readable, the message is consider to be null.
Default policy There is no required text. Customizing Since the message
might be considerably longer than a typical DCL command line, these
tests allow a command line user to progressively
specify text, starting each subsequent value with the character
"+".
selector Limits
| Constraint |
Value |
Default |
|
CONTAINED
|
0-511 characters
|
none
|
|
CONTAINS
|
0-511 characters
|
none
|
|
MATCH
|
0-511 characters
|
none
|
Exemptions
| Constraint |
Value |
Parameters |
|
CONTAINED
|
0-511 characters
|
<node>
|
|
CONTAINS
|
0-511 characters
|
<node>
|
|
MATCH
|
0-511 characters
|
<node>
|
Practical considerations The MATCH constraint is
equivalent to including the same text in both the CONTAINED
constraint and the MATCH constraint.
Comparison treats line-feed, carriage-return, line-feed and form-feed
as equivalent to space. It also treats multiple spaces as equivalent to
a single space and artifically inserts a space before and after any
punctuation characters. While the SYS$WELCOME logical name mechanism
(measured by
WELCOME) can be customized on a per-username basis, the
SYS$ANNOUNCE logical name mechanism (measured by
ANNOUNCE) lends itself better to requirements that the message
stay on a screen until explicit action is taken by the user. (The
explicit action being the entering of a username.)
WRITEBACK
Determine whether file header modifications are delayed in being
written to disk.
Violation reports
| Constraint |
Nature of the violation |
|
PROHIBITED
|
System parameter WRITEBACK is 1 in violation of policy
|
|
REQUIRED
|
System parameter WRITEBACK is 0 in violation of policy
|
Description
These tests check the VMS system parameter ACP_WRITEBACK, which controls
whether file header writes are deferred. Deferring writebacks (the VMS
default) increases the chance that data written to disk could not be
recovered after a system crash.
Default policy Both tests are off, due to the conflicting practical
considerations outlined below, including the political impact of
affecting performance
for security purposes. Customizing If your policy is to avoid deferred
writeback, set (VMS, WRITEBACK, PROHIBITED) to be true. If your policy
is to defer writeback, set (VMS, WRITEBACK, REQUIRED) to be TRUE.
selector Limits
| Constraint |
Value |
Default |
|
PROHIBITED
|
FALSE or TRUE
|
TRUE
|
|
REQUIRED
|
FALSE or TRUE
|
FALSE
|
Exemptions
| Constraint |
Value |
Parameters |
|
PROHIBITED
|
FALSE or TRUE
|
<node>
|
|
REQUIRED
|
FALSE or TRUE
|
<node>
|
Practical considerations Although deferring the writing of file headers
is undesirable from a security (continuity of service) perspective, it
is often highly desired from
a performance perspective (which is why the capability is provided by
DEC).
By default, VMS enabled deferred writeback of file headers, so
prohibiting it by policy will result in considerable interaction with
various system administrators to either get writeback disabled or reach
agreement that an exemption for a particular node should be added to
the policy.
In tight capacity situations, disabling deferred writebacks might be
enough to push a system over the knee of a performance curve. If the
result
prolongs operations significantly, it could increase the window between
file updates and the corresponding file header updates, exacerbating
the very
condition it was meant to alleviate!
those audits or alarms are