| Previous | Contents | Index |
This chapter discusses the uses of assessment modification.
Modification of assessments gives you the ability to
apply
differing policies and transmission media to various
nodes in your organization.
It is rare that an organization which has totally uniform uses for all
VMS systems, and thus it is rare than an organization has totally
uniform security needs for all those systems.
8.1 Adding and Removing Nodes from the Assessment
Specifying the name of a node when modifying a assessment serves to add the node to that assessment.
To remove a node from an assessment modify the assessment to give the node a policy name which is blank. Technically a record of the node will remain in the file (for audit-trail purposes, if nothing else) but the node will not be included when the assessment is run.
On master nodes without DECnet, the master node should be specified as "0" when adding it to an assessment. |
Modifying an assessment to change the
policy associated with a node will cause subsequent
RUN commands for that
assessment to use the new policy. Any previous RUN
commands (even those specifying an AFTER or INTERVAL time)
will use the policy in effect at the time the RUN
command was issued.
8.3 Changing Request Media
Modifying an assessment to change the request medium
associated with a node will cause subsequent RUN commands for that
assessment to use the new request medium. Any previous RUN commands
(even those specifying an AFTER or INTERVAL time)
will use the request medium in effect at the time the RUN command was
issued.
8.4 Changing Result Media
Modifying an assessment to change the result medium
associated with a node will cause subsequent RUN commands for that
assessment to use the new result medium. Any previous RUN commands
(even those specifying an AFTER or INTERVAL time)
will use the result medium in effect at the time the RUN command was
issued.
8.5 Changing Media Protection
Modifying an assessment to change the request or
result medium
protection associated with a node will cause subsequent RUN commands
for that assessment to use the new request or result medium protection.
Any previous RUN commands (even those specifying an AFTER or INTERVAL
time)
will use the request or result medium protection in effect at the time
the RUN command was issued.
8.6 Audit history
The audit history mechanism can be used to show when changes were made to your assessments.
This chapter describes how to access LJK/Security from programs you have written in VMS programming languages.
As used below, names of the form LJK$SECURITY_*_xxx.EXE stand for
both LJK$SECURITY_*_AXP.EXE and
LJK$SECURITY_*_VAX.EXE.
9.1 Master Node Invocation Entrypoints
These entrypoints to the shareable image LJK$SECURITY_SHARE_xxx.EXE are used to invoke LJK/Security from a user program on the master node. Their use on a tributary node is not supported.
By calling these entrypoints, a user program effectively replaces the small program LJK$SECURITY_xxx.EXE which is normally used to process the command LJK/SECURITY.
In order to call these entrypoints, a user program must be linked against the shareable image SYS$LIBRARY:LJK$SECURITY_SHARE or it must invoke the entrypoints within that image by using the VMS function LIB$FIND_IMAGE_SYMBOL.
For successful invocation of anything other than a parsing function, certain privileges are required:
These entrypoints are used to parse LJK/Security commands in
preparation for subsequent execution. If one of them is called without
a subsequent call to the execution entrypoint, it served to
"test"
the command for legality.
9.1.1.1 LJK$SECURITY_PARSE_DCL entry
This entrypoint takes a single parameter which is a string descriptor
of the command to be parsed. It returns status in R0.
9.1.1.2 LJK$SECURITY_PARSE_CLI entry
This entrypoint takes no parameters, but parses the command which was
used to invoke the program. It returns status in R0.
9.1.1.3 LJK$SECURITY_PARSE_FOREIGN entry
This entrypoint takes no parameters, but parses a foreign command
which was used to invoke the program. It returns status in R0.
9.1.2 Execution Entrypoint
9.1.2.1 LJK$SECURITY_EXECUTE entry
This entrypoint takes no parameters, but relies on values previously
determined from a call to a parsing entrypoint. It returns status in R0.
Note that the call to a parsing routine above may produce results which cause multiple subsequent commands to be parsed within the call to the execution entrypoint. Cases where this happen include:
When provided by the customer, this callback is used by LJK/Security to invoke customer-provided software as part of the assessment process.
9.2.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).
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:
$ LINK/NOTRACE/SHAREABLE=LJK$SECURITY_SITE_SHARE_xxx.EXE -
MY_CODE,SYS$INPUT:/OPTION
SYMBOL_VECTOR=(LJK$SECURITY_SITE_CHECKSUM=PROCEDURE)
|
$ LINK/NOTRACE/SHAREABLE=LJK$SECURITY_SITE_SHARE_VAX.EXE -
MY_CODE,SYS$INPUT:/OPTION
UNIVERSAL=LJK$SECURITY_SITE_CHECKSUM
|
9.2.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.2.3 LJK$SECURITY_SITE_CHECKSUM callback
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.2.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 0-254 characters, and
is delivered to the site checksum routine as the corresponding binary
array whose length is 0-127 bytes.
9.2.3.2 Specialized use of Exemptions
Exemptions for the test DISK, CHECKSUM, SITE contain:
The desired Checksum value is specifed as a hexadecimal string whose
length is 0-254 characters, and is delivered to the site checksum
routine as the corresponding binary array whose length is 0-127 bytes.
9.3 Detailed Entrypoint Descriptions
status =LJK$SECURITY_PARSE_DCL (command)
VMS usage: cond_value type: longword (unsigned) access: write only mechanism: by value
command
VMS usage: char_string type: character string access: read only mechanism: by descriptor
The command which is to be parsed. It must start with the string "LJK/SECURITY " (followed by a space).
This entrypoint takes a single parameter which is a string descriptor of the command to be parsed. It returns status in R0.
status=LJK$SECURITY_PARSE_CLI
VMS usage: cond_value type: longword (unsigned) access: write only mechanism: by value
None.
This entrypoint takes no parameters, but parses the command which was used to invoke the program. It returns status in R0.
status=LJK$SECURITY_PARSE_FOREIGN
VMS usage: cond_value type: longword (unsigned) access: write only mechanism: by value
None.
This entrypoint takes no parameters, but parses a foreign command which was used to invoke the program. It returns status in R0.
status=LJK$SECURITY_EXECUTE
VMS usage: cond_value type: longword (unsigned) access: write only mechanism: by value
None.
This entrypoint takes no parameters, but relies on values previously determined from a call to a parsing entrypoint. It returns status in R0.Note that the call to a parsing routine above may produce results which cause multiple subsequent commands to be parsed within the call to the execution entrypoint. Cases where this happen include:
status =LJK$SECURITY_SITE_CHECKSUM (data_address, data_length, initialization_vector, context, callback)
VMS usage: cond_value type: longword (unsigned) access: write only mechanism: by value
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.callback
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 last, this address is zero.
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 CALLBACK parameter should provide the following parameters:
- CHECKSUM
A string descriptor of the checksum computed by the customer checksum routine. This checksum will be compared against the value of the exemption for the specified file, and a violation will be reported if the two values differ, either in length or content.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.
| Previous | Next | Contents | Index |