LJK/Security Reference Manual


Previous Contents Index

* 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.


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.


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 By default 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.


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!


Site-Specific Customization

These chapters discuss mechanisms for using LJK/Security in a fashion appropriate to your own site.


Chapter 7
Policy Modification

This chapter discusses the uses of policy modification.

7.1 Disables

The primary use of disables is to save execution time by avoiding testing of an entire facility. If one of your nodes has an extremely large User Authorization File, for instance, you might choose to test it only once per day, while testing other facilities at the start of each 8 hour shift.

No capability is provided to disable particular tests within a facility, because the time-consuming portion of the testing process is getting the raw information, such as user authorization or file data, which is done once per data item for all the tests in a facility. For instance, once information about a particular file has been retrieved from VMS, the number of tests applied to it in memory does not have a significant effect on performance. Of course, the number of tests failed, and thus the number of violation records written, can affect performance.

Newly created policies have all facilities enabled by default.

7.2 Limits

Limits are the cornerstone of policies, setting the basic criteria by which nodes will be assessed. As supplied, LJK/Security provides a default set of limits for each policy you create, but after you have used the software for a while it is likely you will want to make some changes to suit your own organization's needs.

Newly created policies have a default value for each limit, either taken from the policy named DEFAULT or from the factory defaults. When you customize a policy by changing particular limits, all other limits retain their value unless you change them.

Any comments applied to limits (but not comments applied to disables or exemptions are included in violation reports created by LJK/Security. As such they can be used to indicate the authority by which a particular limit was set, such as a particular internal memo or some external requirement such as a particular control listed in NIST Special Publication 800-53.

Disabling tests entirely is only done on a facility-wide basis through the use of disables (see Section 7.1).

7.3 Exemptions

Exemptions provide a finer control over reporting of assessment results, allowing for policy deviations in specific cases. 1

Note

Limit, exemption and disable values you have customized are retained when you update to a newer version of LJK/Security software. Any new kinds of limits and disables implemented by the new version will be added to your existing policies with default values as needed.

Certain exemptions are normal, since the conditions they permit are required for normal operation of VMS. These exemptions are not automatically generated by LJK/Security software, since LJK Software believes that sites should always be aware of all exemptions added to their policies. Exemptions LJK Software has identified that most sites will want to add are:

Note

1 Except for Disk tests, exemption processing is done when receiving results on the master node. Thus no processing time is consumed on the tributary nodes due to a long list of exemptions.

7.4 Audit history

The audit history mechanism can be used to show when changes were made to your policies. Preservation of this audit history is the reason why LJK/Security provides no command to delete a policy or an assessment.

7.5 Tri-valued logic

Some tests take limit and exemption values using tri-valued logic:

The meaning of the value TRY is to enforce the test in question only on those versions of VMS where such capability is provided. The value TRY can be used in cases where you desired to ignore situations where the version of VMS being run is unable to follow the policy. Avoiding the value TRY causes violations to be reported if the policy cannot be followed due to the version of VMS being run.

7.6 Boolean customization techniques

Many elements have tests for exactly two boolean constraints, PROHIBITED and REQUIRED. With these two boolean tests, there are four possible limit settings:
Value of REQUIRED limit Value of PROHIBITED limit
  FALSE TRUE
FALSE never report a violation report violation if TRUE
TRUE report violation if FALSE always report violation
Although it departs from the LJK/Security design of management by exception, the specification to always report a violation may be useful in certain limited circumstances such as described in Section 11.1.

7.7 Numeric customization techniques

Many elements have tests for exactly two numeric constraints, ABSOLUTLO and ABSOLUTHI. If the limits for these two numeric tests are set such that the ABSOLUTHI limit is lower than the ABSOLUTLO limit, the result is to report violations in all cases, similar to setting both limits TRUE as described in Section 7.6.

7.8 Policy Performance Considerations

There are three major areas where the performance of LJK/Security is drastically affected by policy choices:

  1. Password Guessing
    If your policy sets a high limit for the (UAF,PWDGUESS,TRIES) test for large numbers of users (based on how many have various privileges), assessment of tributary systems will be slowed down considerably.
  2. General disk processing
    Scanning disk files can have considerable disk performance impact on users while LJK/Security is running on a tributary system. In some cases, assessments whose policies include the disk facility are run only during non-prime hours.
  3. ACL evaluation
    Evaluating ACLs can take considerable CPU time. To avoid this for certain policies, turn off the following tests:
In addition, excessive numbers of exemptions for a single test can slow down processing violations of that test considerably.

Finally, violation processing in general is slow. It is better to run a less ambitious policy until the most outrageous security errors are brought under control.

7.9 SHOW POLICY/COMMAND_PROCEDURE

The /COMMAND_PROCEDURE output of the SHOW POLICY command produces a command procedure that can be modified to give exactly the same settings to some other policy. The strength of this capability is not in exact duplication, but rather in tailoring the output to produce a slightly different result.

As generated, the output from /COMMAND_PROCEDURE puts all the limits for a particular test together (and all the exemptions for the same test together somewhere else). If you want to arrange the output in alphabetic order, use a command like:


$ SORT MY_FILE.COM MY_FILE.COM /KEY=(POSITION=1,SIZE=60)/STABLE 
This takes care of two issues:

  1. Not sorting lines for a single test according to selector names, thus preserving the logical (not textual) ordering.
  2. Not sorting lines for multiple lines used to compose a single limit or exemption formed using the leading "+" syntax for (VMS, ANNOUNCE) or (VMS, WELCOME).


Previous Next Contents Index