LJK/Security Reference Manual

Appendix G
Bug Reports

This appendix tells how to report problems to LJK Software.

There is opportunity for lengthy debate over what is a "bug", what is a "feature", when a "bug report" is really an "enhancement request" and similar issues.

Rather than semantic nit-picking, however, the purpose of this appendix is to discuss communications between you, the user of LJK/Security, and LJK Software, the vendor and maintainer.

Even in cases where there is no problem with the software, user reports of difficulties give LJK Software information as to where documentation or training can be improved, so we appreciate your input.

At the same time, both parties want to make these interactions as productive as possible, and it is to that purpose that these suggestions are directed.

G.1 Isolating the Problem

As with any computer problem, the first step is to narrow down the exact nature of the problem. Does a particular command fail only with certain menu choices, or only on certain policy files? Does a particular assessment have problems only on certain nodes? How do those nodes differ from nodes on which the assessment succeeds?

Such questions will involve your participation, either before or after you contact LJK Software customer support.

G.2 Log Files

Area LJK$SECURITY_ACTION_AREA: contains log files from network and detached processes used by LJK/Security. Examining these logs may be helpful in troubleshooting. Reading them requires full system management privileges.

G.3 Getting an Initial Opinion

In many cases software support people can offer immediate answers because they deal with a product very regularly. In most cases you will want to contact LJK Software customer support before you go to the trouble of transmitting data files, since it may be a problem previously reported from another site.

G.4 Collecting information for LJK Software

In the case of some thornier problems the information you are able to provide via terminal or voice telephone is not sufficient to resolve the problem, and you may be asked to send files that illustrate the problem such as:

command procedures that reproduce the problem
If this can be provided it usually leads to very quick isolation of the cause, but especially with an interactive product like LJK/Security, command procedures are not appropriate for many operations.
An alternative for some sites is an interactive test file created with the DEC/Test Manager. Sites that do software development may have that optional software installed, and in some extreme cases of problems that LJK Software is unable to reproduce, shipping a test file might be helpful.
log files that show the problem
The command:
$ set host 0/log=filespec
can be used to record the output from an interactive session. In cases where a command file to reproduce a problem is not possible, a log file that documents it can be quite helpful.
Copies of policy and assessment files
LJK/Security policies and assessments are stored as indexed files in the directory described by system logical name LJK$SECURITY_POLICY_AREA. Copies of the relevant files can sometimes be helpful.
Copies of log files
LJK/Security log files are stored in the directory described by system logical name LJK$SECURITY_ACTION_AREA. Copies of those files can sometimes be helpful.
Process dump files
If the detached process LJK/SECURITY on the master node should abnormally terminate, a dump file will be written to the directory described by system logical name LJK_SECURITY_ACTION_AREA. That file is extremely helpful to LJK Software in analyzing the cause of termination.
Result files
Files whose types are .LJK$SECURITY_RESULT and .LJK$SECURITY_LOCAL_RESULT might be helpful in certain rare cases, but since they contain a list of security vulnerabilities of your systems, you may prefer not to pass them along to any outside party, including LJK Software. That is your decision to make should other analysis approaches fail.

Exactly which of those files might be helpful will depend on the nature of the problem, and the LJK Software representative will suggest which files would be most helpful.

Appendix H
Hints and Kinks

This appendix gives information not of general interest, such as discussion of internal operation of LJK/Security.

H.1 LJK/Security Version Compatibility

LJK/Security data file version compatibility should be considered in three areas:

Policy files
Policy files created with other versions of LJK/Security will operate correctly. In cases where a tributary node is sent an older policy, it will use the factory default values for any new tests not covered in the policy. A message regarding that defaulting will be included in the result file. Modifying any component of that policy on the master node will update the master node copy of that policy and eliminate the messages.
Assessment files
Assessment files created with other versions of LJK/Security will operate correctly.
Result files
A particular version of LJK/Security cannot process result files which contain codes for unknown violations. This means that tributary nodes cannot be running versions of LJK/Security which contain new tests, relative to the version running on the master node.
Since tributary nodes get their software from the master node, there are only two ways this situation could occur:
- Multiple master nodes are used in a single VAXcluster or VMScluster and they have separate system disks with different versions of LJK/Security on them.
- The version of LJK/Security on the master node is rolled back after software distribution to tributary nodes, and the old version is not redistributed to those nodes which have the new version.
Note that the latter situation will also cause problems with existing result files on the master node which were created when the newer version of LJK/Security was installed.

H.2 Tributary node disk space

In performing an assessment on a tributary node LJK/Security could potentially fill the system disk if the policy specified for that node is considerably more strict than the actual security state of the node.

In a worst case situation, the system administrator who neglected to use disk quotas on the tributary node system disk may also have VMS audit server settings which cause the system to pause user operations or crash when no system disk space is available for the audit server (see LJK/Security Audit facility tests FINCRASH, FAILWAIT and FAILCRASH).

The following measures are taken by LJK/Security to avoid such problems.

H.2.1 With disk quotas

When disk quotas are enforced on the tributary node system disk (as they should be for good security), LJK/Security will run out of disk quota if excessive violations are encountered. At that point, LJK/Security will attempt to write one more record before terminating testing of the current facility. That record will contain an indication of the fact that disk space was exhausted and not all violations were reported. That extra record can only be written if there is some extension disk quota available for username LJK$SECURITY, so LJK Software recommends that username LJK$SECURITY be given an extension disk quota equal to 40 times the number of LJK/Security facilities (since 40 is the file extension increment used for intermediate result files on tributary nodes.

If no extension disk quota is available, LJK/Security in most cases will terminate on the tributary node, leaving the master node without specific information regarding the nature of the failure. (It is difficult to save status for transmission back to the master node if there is no space to save it.)

H.2.2 Without disk quotas

Regardless of disk quota limitations, LJK/Security will not use more than 50% of the tributary node disk space which was present at the start of the assessment. This prevents LJK/Security from being the sole cause of a disk filling, but there is still the possibility that a disk without quotas might fill due to the combined action of LJK/Security and some other program. (Of course, the same can be said for a disk where quotas are in use but excessively high quotas are given.)

In general, our security judgement is that if your policies are close to filling the disk with violations, a more lenient policy would be in order until the more critical security problems are eliminated.

H.3 Changing Template Terminal UCB Characteristics

If an ordinary VMS terminal has an incorrect setting of the dialup characteristic, it can be corrected with a command such as:

$ SET TERMINAL TXC7:/DIALUP/PERMANENT

in the system startup command procedure.

In the case of LAT terminals or TCP/IP Telnet terminals from various vendors, the VMS terminal devices are created on the fly, taking their characteristics from a "template UCB".

The operation of a template UCB is that when an attempt is made by a program to connect to it, the connection instead is made to a cloned UCB created at the time. Thus it is not possible for programs to actually connect to the template UCB in order to change the characteristics, such as would be done by the SET TERMINAL command above!

One method which generally works to change the characteristics of template UCBs is to set the relevant VMS system parameters (TTY_DEFCHAR or TTY_DEFCHAR2) before the template UCB is created (during system startup). At least through VMS V8.3 these system parameters are unfortunately not dynamic parameters, and require rebooting VMS for changes to take effect.

Thus all terminal template UCBs can readily be set one way or the other, but treating some template UCBs different from others will be difficult so long as the VMS system parameters involved are not dynamic.

Individual products which supply terminal drivers can provide their own mechanism for setting such characteristics, and Release 3.1 of Process Software's Multinet TCP/IP product is reported to add such a capability for the dialup/local characteristics setting.

H.4 Autologin file record length

VMS symbol definition files such as LIB.REQ define the length of a record for the file SYSALF.DAT as being 128 bytes. The DCL command procedure ALFMAINT.COM provided with VMS through VMS V5.4, however writes those records as being 126 bytes long (even though it defines the record length for the file as being 128 bytes).

LJK/Security will accept autologin file records with lengths of 125 bytes or more. If a shorter autologin file record should be written in the future, an error will be returned to the master node.

H.5 Avoiding PRODUCT INSTALL

LJK Software supports use of VMSINSTAL.COM rather than PRODUCT INSTALL because of several issues in various versions of VMS:

PRODUCT INSTALL does not allow choice of UIC for accounts created
PRODUCT INSTALL gives a warning message when an account must be created with different characteristics on different versions of VMS
PRODUCT REMOVE will remove accounts it created even when shared in a cluster.

H.6 REPORT output

The output of the REPORT command takes several lines for each violation found, but LJK/Security has been designed so that when that output is directed to an RMS file each violation is in a single RMS record. This means the output file is susceptible to the VMS command SEARCH (for example) searching on the test name and returning the entire violation record.

H.7 Renaming and Copying Files

The policy and assessment files in LJK$SECURITY_POLICY_AREA: are independent data, and can be renamed or copied using normal VMS utilities. (Of course if a policy no longer exists, any assessment depending on it will not function properly.)

Such renaming is an abnormal action and requires VMS privileges for system management.

H.8 DCL Symbol Processing

Normally DCL symbol substitution is available on commands issued at the DCL prompt but not for commands issued within a program such as in LJK/Security Subsystem mode. Within LJK/Security Subsystem mode, however, a special case exception is made for

Assessment Names
Policy Names

used as parameters of the commands

CREATE
MODIFY
SHOW

This special treatment facilitates command procedures such as those discussed in Appendix K, Creating Policies Based on Examples or those created with the command:

LJK/SECURITY SHOW POLICY/COMMAND_PROCEDURE

Those command procedures are able to accept a name as a parameter and use it on each MODIFY command in Subsystem mode without incurring the overhead of exiting to DCL after each MODIFY and activating the LJK/Security images again.

H.9 Hexadecimal Alarms After Upgrading LJK/Security

Upgrading LJK/Security provides a new LJK$MESSAGES file which may contain messages not present in an earlier version of the file. If those messages are used in alarms, the alarm text may show the "Event information:" as a hexadecimal number (e.g. "Message number 0239F7BC") rather than the new text (e.g. "LJK/Security Assessment ran for certain facilities").

This behavior can be corrected by restarting the VMS Audit Server, which causes it to start using the new version of the file in future alarm messages.

H.10 Analyzing Network Problems

H.10.1 SS$_LINKEXIT

Sometimes a status command like:

$ LJK/SECURITY REPORT STRICT_ASSESSMENT/STATUS

will produce an indication that a result is not complete due to continuing network problems like:

after < none > interval < none > FARNOD 17-SEP-2004 00:38 due POLICY_MOST_STRICT %SYSTEM-F-LINKEXIT, network partner exited

In this particular case someone can log in interactively to a username on FARNOD that has system management privileges and look at the contents of the file:

LJK$SECURITY_ACTION_AREA:NETSERVER.LOG

for hints regarding the nature of the problem.

H.10.1.1 No such file as NETSERVER.LOG

If there is no such file, it might be helpful to test a different DECnet connection from the master node to the tributary node with a command like:

$ DIRECTORY FARNOD"username password"::LOGIN.COM;

H.10.1.2 SS$_STKOVF

If one of the LJK$SECURITY_ACTION_AREA:NETSERVER.LOG files shows a connect request received, followed by an improperly handled condition with a signal argument name of 554 and the message:

%SYSTEM-F-STKOVF, stack overflow

one possible cause is inadequate process quotas on the receiving end. Although the DECnet process is running under the auspices of username LJK$SECURITY, the manner in which NETACP creates such processes without using DECnet proxies (at least up through VMS V7.3-2 when this text is being written) specifies STSFLG bit 40 hexadecimal, meaning quotas from the authorization file have been ignored and the created processes takes quotas from the creating NETACP process.

One method of increasing quotas for those DECnet processes is to modify minimum process quotas through PQL_M* system parameters like PQL_MPGFLQUOTA. That will increase quotas for any processes at that lower limit, but extra quota for processes that do not use it should not affect system operations (unless there are processes on the system which you want to fail for lack of quota).

H.11 Analyzing Installation and Licensing Problems

H.11.1 LJK$_NOMASTER

When running the first assessments after installation with a command like:

$ LJK/SECURITY RUN STRICT_ASSESSMENT

it is possible to get the error:

%LJK-E-NOMASTER, No master LJK/Security process on this node with current license

in cases where LJK/Security was installed before the license for LJK/Security was loaded.

To resolve this situation, someone with appropriate access to LJK/Security should issue the command:

LJK/Security SHUTDOWN

and someone with system management privileges should then should issue the command:

@SYS$STARTUP:LJK$SECURITY_STARTUP

Contents

Index

LJK/Security Reference Manual

Appendix GBug Reports

Appendix HHints and Kinks

H.2 Tributary node disk space

H.6 REPORT output

Appendix G
Bug Reports

Appendix H
Hints and Kinks