LJK/Security Reference Manual
Previous Contents Index

Those terms needed by your Report Formatting module should be stored away by your POLICY_TERMS entrypoint for use during calls to your other entrypoints.

Keep in mind that your POLICY_TERMS entrypoint can be called multiple times, once for each policy used in a given assessment. Storage of the strings provided to your POLICY_TERMS entrypoint should be indexed according to the POLICY_NUMBER parameter provided to the call.

A Boolean value returned by this entrypoint indicates whether processing of this report should continue. A value of FALSE will terminate processing.

9.3 Tributary Node Callout Entrypoint

When provided by the customer, this callout is used by LJK/Security to invoke customer-provided software as part of the assessment process.

9.3.1 Linking of Customer-Provided Software

Customer-provided software should be linked into a shareable image named LJK$SECURITY_SITE_SHARE_xxx.EXE. The linking should be done on the oldest version of VMS on which LJK/Security is to be run. The link should be done without traceback symbols, so that the shareable image can be called by an image installed with privilege (LJK$SECURITY_xxx.EXE).

Note
There is no requirement that LJK/Security be on the node where the link is performed.

The entrypoint LJK$SECURITY_SITE_CHECKSUM should be declared as a universal symbol so that it can be accessed from outside the image. Example link commands are:

For AXP: 


$ LINK/NOTRACE/SHAREABLE=LJK$SECURITY_SITE_SHARE_AXP.EXE - 
    MY_CODE,SYS$INPUT:/OPTION 
SYMBOL_VECTOR=(LJK$SECURITY_SITE_CHECKSUM=PROCEDURE)

For VAX: 


$ LINK/NOTRACE/SHAREABLE=LJK$SECURITY_SITE_SHARE_VAX.EXE - 
    MY_CODE,SYS$INPUT:/OPTION 
UNIVERSAL=LJK$SECURITY_SITE_CHECKSUM

9.3.2 Distribution of Customer-Provided Software

If the image LJK$SECURITY_SITE_SHARE_xxx.EXE is stored in the directory SYS$COMMON:[SYSLIB] on the master node, then it will be automatically included by LJK/Security in software distributed to tributary nodes. In the distribution process, the protection will be changed to at least allow Execute access to World.

9.3.3 LJK$SECURITY_SITE_CHECKSUM callout

This entrypoint is called successively during the process of checksumming a file. Before each call, a succeeding segment of the file is mapped into the address space of the process (although the segment mapped on the final call may be null) and thus is available to be read by the site routine.

9.3.3.1 Specialized use of the Limit

The limit for the test DISK, CHECKSUM, SITE is not actually a limit in the general sense of LJK/Security, but rather is used to store any Initialization Vector required by the site checksum routine. The Initialization Vector is specified as a hexadecimal string whose length is an even number of 0-254 characters, and is delivered to the site checksum routine as the corresponding binary array whose length is 0-127 bytes.

9.3.3.2 Specialized use of Exemptions

Exemptions for the test DISK, CHECKSUM, SITE contain: Like normal exemptions for the FILE facility of LJK/Security, file specifications can be qualified by node name. There is no requirement that the file to be checksummed be an executable image. No error is issued if the file is not present, so multiple nodes can be supported from a single policy even when certain files only exist on a subset of the nodes.

The desired Checksum value is specifed as a hexadecimal string whose length is an even number of 0-254 characters, and is compared to the checksum provided by the site checksum routine to the callout routine (as the corresponding binary array whose length is 0-127 bytes) after processing the final segment.

9.3.4 Detailed Checksum Entrypoint Description

The following pages contains a full description of the Checksum entrypoint.

LJK$SECURITY_SITE_CHECKSUM

Perform a checksum using a customer-implemented algorithm, for instance to use a different algorithm than those supplied with LJK/Security or to use a different implementation of an algorithm also supplied with LJK/Security because that implementation has been approved by some higher authority.

Format

status =LJK$SECURITY_SITE_CHECKSUM (data_address, data_length, initialization_vector, context, callout)

RETURNS

VMS usage: cond_value
type: longword (unsigned)
access: write only
mechanism: by value

Arguments

data_address


VMS usage: vector_byte_unsigned
type: byte array
access: read only
mechanism: by reference

The address of the current segment to be included in the checksum.

data_length


VMS usage: longword_unsigned
type: unsigned longword
access: read only
mechanism: by reference

The number of bytes in the current segment to be included in the checksum.

initialization_vector


VMS usage: vector_byte_unsigned
type: byte array
access: read only
mechanism: by descriptor

A fixed length string descriptor of the initialization vector supplied as the limit in the LJK/Security policy. By default, policies contain a zero length string.

context


VMS usage: longword_unsigned
type: unsigned longword
access: read-write
mechanism: by reference

The address of a longword of unspecified purpose for use by the customer-provided checksum routine. One typical use is to store in this longword the address of a segment of allocated memory used for maintaining algorithm context. On the first call for a particular file, this longword contains zero. On subsequent calls, the contents of this longword (as left by the previous call) are preserved. On return from the last call for a particular file, this longword should again be changed back to zero, indicating that memory has been properly deallocated.

callout


VMS usage: entry_mask
type: entry mask
access: read only
mechanism: by reference

The address of the entry mask of a routine to be called after processing the last segment. The presence of this address indicates the last segment. On segments other than the final segment, this address is zero.

Description

This subroutine will be called multiple times for each file to be processed, with the last call specifying a data length of zero. On short files, therefore, only two calls will be made, where the demarcation size between short files and long files is based on the amount of free virtual address space.

The call made by a customer checksum routine to the entry specified by the CALLOUT parameter should provide the following parameters:

If entrypoint LJK$SECURITY_SITE_CHECKSUM returns status (R0, as specifed in the VMS calling standard) which is other than success (low order three bits containing other than the value 1), that status will be returned to the master node and reported as a processing failure by LJK/Security.

Chapter 10
Using LJK/Security With Removable Media

This chapter describes the differences involved in using magnetic tape or removable disks rather than DECnet for communication between the master node and tributary nodes.

A special case DECnet alternative for those who have TCP/IP connectivity but are forbidden to run DECnet is described in Appendix L, Sending LJK/Security Data Directly over TCP/IP.

10.1 Reasons

Although using magnetic tape or removable disks to carry LJK/Security information between the master node and the tributary nodes generally requires more human effort than using DECnet, there are two principal reasons why one might choose removable media instead of DECnet:

  1. Lack of DECnet Connection
    The lack of a connection obviously means that DECnet cannot be used, and removable media are the only alternative.
  2. Lack of DECnet Bandwidth
    If the master node is connected to many of the tributary nodes by only a very narrow-bandwidth DECnet link (e.g., 1200 baud asynchronous), removable media may be better for transport than DECnet.
    Since Section 2.1 suggests that DECnet bandwidth be taken into account when choosing a master node, if bandwidth is a problem presumably the choice of master node was made for other reasons.
  3. Security
    It is conceivable that a skillful attacker could monitor DECnet traffic on a link or on an intervening DECnet routing node to learn vulnerabilities discovered by LJK/Security on some other system.
    It is also conceivable that a skillful attacker could attempt to interfere with LJK/Security DECnet traffic, preventing collection of information about vulnerabilities.

    Note
    Using removable media for transport between a master node and that same node as tributary node does not particularly add to security. The best that can be said for it is that it gives practice in using the removable media for transport!

There are three types of LJK/Security communication between the master node and the tributary node:

The choice of medium is made independently for each type for each tributary node, so choosing a removable medium in one case does not prevent DECnet from being used in another.

10.2 Software Installation

To minimize the complication introduced by installation of LJK/Security, the installation on tributary nodes has been kept very simple. The only information which must be supplied by the person installing the software on the tributary node pertains to the UIC code used for storing LJK/Security files. This is intended to ease the task of VMS system managers at tributary nodes who are likely to have other tasks assigned to them with higher priority than security. For Software Installation, the use of removable media provides a very familiar environment for the individual doing the installation (so long as the medium used is the same one used for other software installations).

Using magnetic tape as an example, the LJK/Security on the master node would use the LJK/SECURITY KIT_BUILD command to write a tributary node software kit onto magtape. After the magtape is transported to the tributary node, it is installed like any other piece of software, using the standard VMSINSTAL command procedure: 


$ @SYS$UPDATE:VMSINSTAL * ddcu:
where ddcu: is the device on which the removable medium is mounted.

Unlike the transmission types below, a single copy of the LJK/Security tributary node software is sufficient; it can be installed on multiple tributary nodes in succession.

10.3 Request Transmission

For request transmission, when the LJK/SECURITY RUN command is issued (or when it comes due following the use of /AFTER or /INTERVAL command) on the master node, LJK/Security will issue a MOUNT request to write each request onto its specified medium. (Be sure to have at least one terminal enabled as an operator terminal for the appropriate medium (disk or tape) using the VMS command REPLY/ENABLE, or transmission of the request will be delayed.

In cases where the MOUNT request specifies one tape drive and the operator prefers to use another tape drive of the same type, LJK/Security will honor the "SUBSTITUTE" argument to the REPLY command. If tape drive MUA2: should be used instead of the requested drive (due to hardware problems, for example) the operator could issue the command: 


REPLY/TO=37429 "SUBSTITUTE MUA2"
Programs are so often written to prevent use of this handy VMS feature, that LJK Software felt it important to point out that LJK/Security honors such replies.

After the medium has been transported to the tributary node, any user with the the facility-specific identifier 1 LJK$SECURITY_ROLE_STARTUP or LJK$SECURITY_REMOTE can issue the command: 


$ SUBMIT SYS$SYSTEM:LJK$SECURITY/PARAMETER=ddcu:
to cause LJK/Security to call for the medium to be mounted, where ddcu: is a device (or generic device) specification on which the removable medium can be mounted.

Note

1 On systems prior to VAX VMS V6.0 or systems which do not have a Rights Database (RIGHTSLIST.DAT), you must have the SECURITY privilege.

10.4 Result Transmission

For result transmission, when the assessment has been completed on the tributary node LJK/Security will issue a MOUNT request to write results onto the specified medium. (Be sure to have at least one terminal enabled as an operator terminal for the appropriate medium (disk or tape) using the VMS command REPLY/ENABLE, or transmission of the results will be delayed.

After the medium has been transported to the master node, any user with the the facility-specific identifier 2 LJK$SECURITY_ROLE_STARTUP or LJK$SECURITY_REMOTE can issue the command: 


$ SUBMIT SYS$SYSTEM:LJK$SECURITY/PARAMETER=ddcu:
to cause LJK/Security to call for the medium to be mounted, where ddcu: is a device (or generic device) specification on which the removable medium can be mounted.

Note

2 On systems prior to VAX VMS V6.0 or systems which do not have a Rights Database (RIGHTSLIST.DAT), you must have the SECURITY privilege.

10.5 Relation to Labeling

Various shops have various policies regarding the labels encoded on removable media, some for instance, always want labels preserved. For this reason, LJK/Security takes a very cautious attitude toward labels: labels are never rewritten for request or result transmission.

10.5.1 No File Deletion

Because local removable media labeling policy is not known, LJK/Security request or result transmission does not delete files from removable media or reinitialize removable media. Users should ensure that media provided in response to LJK/Security mount requests have been initialized.

10.5.2 Avoiding Premounted Media

As a safeguard against possibly writing on a tape left on a drive, LJK/Security always attempts an initial mount with the /NOASSIST qualifier. If that succeeds, it then dismounts the medium and requests another mount to force human intervention.

Previous Next Contents Index