Multics Technical Bulletin MTB-698
Answering Service Auditing
To: Distribution
From: Eric J. Swenson
Date: 01/09/85
Subject: B2 Answering Service Auditing Changes
1 ABSTRACT
This MTB describes proposed changes to the Answering
Service to meet the B2 criteria for auditing. Since
this software has not yet been written, this MTB will
take the form of a functional specification. After the
implementation, any changes and implementation details
will be incorporated into a revision of this MTB.
Comments should be sent to the author:
via Multics Mail:
Swenson at either System-M, MIT, or CISL-SERVICE.
via Forum:
>udd>m>mtgs>B2 on System-M
via telephone:
(HVN) 492-9365, or
(617) 492-9365
_________________________________________________________________
Multics project internal working documentation. Not to be
reproduced or distributed outside the Multics project without the
consent of the author or the author's management.
MTB-698 Multics Technical Bulletin
Answering Service Auditing
2 INTRODUCTION
The B2 security evaluation noted several deficiencies in the
auditing performed by the answering service and related software.
These deficiencies are described in detail in the following
section. Section 3 discusses the proposed changes which will
satisfy the B2 security criteria.
3 CURRENT DEFICIENCIES
This section describes several deficiencies in the answering
service and in the system adminstrative software which must be
improved upon in order to meet the minimum requirements specified
in the DoD Computer Security Center Criteria for the B2 rating.
3.1 No Auditing of PNT Changes
When entries in the Person Name Table (PNT) are changed, there is
no record of these changes and no auditing of those who make the
changes. Because the PNT contains critical information such as
authorization ranges, passwords, audit flags, and various flags
which affect the way a user is identified by the system and
authenticated, it is imperative that some mechanism be
established to record changes to the PNT and the nature of these
modifications.
3.2 Authorization Changes in the PNT Have No Effect on Logged-in
Users
If a system administrator changes the authorization range in the
PNT for a logged-in user in such a manner as to make the logged
in instance's authorization inconsistent with the new
authorization range, there is currently no software to forcibly
log out the user. When changes are made to the authorization
ranges stored in the SAT, PDT, and CDT, however, the Answering
Service does bump the inconsistent processes. For consistency,
it is desirable to perform this service for PNT authorization
changes.
3.3 Identification and Authentication Records are Incomplete
It is desirable to have a secure audit trail of all successful
and denied access to the system. While Multics currently audits
almost all access to the system, it fails to account for several
ways a user can cause the system to act on his/her behalf. In
addition, the only audit messages for successful access to the
Multics Technical Bulletin MTB-698
Answering Service Auditing
system are logged at inappropriate times, so it is possible to
have a user of a communications channel identified and
authenticated for quite some time with no record of the
identification. An example of this, is the so-called "connect
loop". When a user issues the "login" preaccess command, and is
identified by name and authenticated by password and system
tables, but the system is unable to determine what to do because
the user has disconnected processes, the user is placed in the
"connect loop". No audit record has been made to describe this
situation. Various requests are available to the user at this
point, but only some of the requests provoke audit messages.
The Criteria require that security-relevant information be
included in each audit record. Answering Service audit records
(by virtue of their lack of anything other than a text-string)
have been of necessity lacking all the relevant security
information (e.g. authorization range, authorization, ring
information, etc.) They have typically been difficult to read by
humans and just as difficult to parse by auditing programs.
Attempts to use the "dial" and "slave" preaccess commands are not
properly audited. The recent support for identification and
authentication of dial/slave use lacks accurate audit trails.
3.4 Communication Channel Audit Messages are Incomplete
The answering service provides the capability for a process to
attach communications channels other than the login channel. It
does this by accepting answering service requests from processes,
making its own access checks, and auditing successful and denied
access to communications channels. The current audit messages do
not contain complete security information, nor are they
syntactically symmetric. Under some circumstances, no audit
messages are produced at all.
4 PROPOSED CHANGES
4.1 PNT Auditing
In order to leave an audit trail of changes to the PNT, the
ring-1 PNT module, pnt_db_util_, will be modified to call the
already installed access_audit_r1_ to perform auditing. Auditing
will be done whenever a PNT entry is added, deleted, or modified.
The audit record will consist of the customary textual portion,
as well as a binary part. The text will contain a terse
description of the PNT change, and the binary will contain both a
MTB-698 Multics Technical Bulletin
Answering Service Auditing
copy of the old security-relevant fields and the new values of
these fields. In the case of a PNT entry deletion or addition,
only one of the two copies will be filled in. Passwords will NOT
be stored in the audit records; flags will be used to identify
changed passwords. The following structure will be used for the
binary portion of the audit messages:
dcl 1 pnt_audit_record structure aligned based,
2 version fixed bin (9) unsigned unaligned,
2 pad1 bit (27) unaligned,
2 flags unaligned,
3 add bit (1) unaligned,
3 delete bit (1) unaligned,
3 modify bit (1) unaligend,
3 password_changed bit (1) unaligned,
3 network_password_changed bit (1) unaligned,
3 pad2 bit (31) unaligned,
2 user_id char (32),
2 old_pnt_entry like pnt_audit_entry,
2 new_pnt_entry like pnt_audit_entry;
dcl 1 pnt_audit_entry structure aligned based,
2 flags like pnt_entry.public.flags,
2 alias char (8),
2 authorization (2) bit (72),
2 password_timelock fixed bin (71),
2 audit_flags bit (36);
Note: The extra pad space in the pnt_audit_record structure is
necessary to get the old_pnt_entry/new_pnt_entry to aligned
themselves on an even word boundary. These structures will be
imbedded in a header which will include the log class and the
access operation to be compabible with the ring-0 audit messages.
The text portion of the PNT audit messages will look something
like:
AUDIT (pnt_db_util_): SCAkers.Scouting modified PNT entry for
GDixon: Changed password,audit_flags
4.2 PNT AIM Changes and Bumping User Processes
In order to bump users whose PNT authorizations are changed in a
manner which would disallow a currently logged in instance of the
user, the Ring-1 PNT software must be able to cause the answering
service to notice the PNT change. A new answering service
request will be added, valid only when requested from Ring-1,
which notifies the answering service of PNT changes. The PNT
software will only use this request when the AIM range of a user
Multics Technical Bulletin MTB-698
Answering Service Auditing
is changed in such a way as to be more limiting, or when a PNT
entry is deleted. Future changes may cause other PNT changes to
have immediate effect.
When the answering service receives the new NOTE_PNT_CHANGE
answering service request, it will validate the request by
ensuring it was submitted from Ring-1, check to see if there are
any logged in instances of the user specified in the request
structure, and if there are, retrieve the PNT entry for the
specified user. It will then compare the PNT authorization range
with the authorization fields in the user_table_entry (UTE) for
the specified user and adjust the UTE values accordingly. If the
current user authorization is inconsistent with new PNT
authorization range, the user will be bumped with no grace
period. Reducing the authorization range of a user, which has
parallels in the military environment of taking away a clearance,
should provoke immediate consequences. Note that the reason for
adjusting the authorization range in the UTE is that attempted
new_procs use these values in the UTE rather than recomputing the
access range from the various tables.
If a user's PNT entry is deleted, the answering service will bump
any currently logged in processes for that user. For the same
reason that no grace time is given for authorization changes, a
user deleted from the PNT will be given no grace time when
bumped. Note that deleting a user's PNT entry should be a very
rare occurrance when the user is still using the system, so
bumping with no grace should not be considered as too drastic.
The proposed implementation only causes processes to be bumped
for AIM changes and PNT deletions. Other PNT attribute changes,
such as turning on the "lock" flag, do not take effect until the
next login.
4.3 Binary Data in Answering Service Audit Records
There is currently no way to associate binary data with Answering
Service audit records. This necessarily limits the amount of
information in audit records and has resulted in very clumsy
audit messages in previous releases. The sys_log_ mechanism,
which both routes textual messages to the message coordinator and
to the answering service log, cannot handle binary data. With
the new-format logs recently installed and utilized by the
answering service, binary data can be included in log entries
with minor software changes.
In order to record security-relevant information of use to a
system security administrator in answering service audit entries,
this MTB proposes a new entry, sys_log_$binary, which performs in
MTB-698 Multics Technical Bulletin
Answering Service Auditing
much the same way as the sys_log_ entry, but which allows
specification of binary data to be included in the log. The
declaration and calling sequence follows:
dcl sys_log_$binary entry options (variable);
dcl severity fixed bin (17);
dcl caller char (32);
dcl data_ptr ptr;
dcl data_lth fixed bin (17);
dcl data_class char (16) varying;
call sys_log_$binary (severity, caller, data_ptr, data_lth,
data_class, ioa_control_string, ioa_arg_1,
ioa_arg_2, ... ioa_arg_N);
where:
severity
is a standard sys_log_ severity
caller
is the caller on whose behalf the message is logged
data_ptr
pointer to binary data
data_lth
length of binary data (in words)
data_class
arbitrary character string identifier used by the expansion
procedures
This entry functions in a similar manner as the current sys_log_
entry, handling the various severity messages and routing them
over the various I/O switches. The only differences are the
addition of binary data and the associated class, and the
provision for a caller name which is automatically placed at the
beginning of the text portion of the log message.
4.4 Changes to Identification and Authentication Audit Messages
In order to more accurately audit instances of successful or
failed login attempts, the answering service log entries will be
changed somewhat to make them more consistent. When a user is
identified (by personid) and authenticated (by password and
system tables) by the program lg_ctl_, an entry will be placed in
the AS log immediatedly. It will take the form:
LOGIN Personid.Projectid {int|abs|dmn|opr} Channel (state)
Multics Technical Bulletin MTB-698
Answering Service Auditing
When the communications channel over which a user has been
"logged in", is no longer considered identified and authenticated
by the answering service, a log entry will be made of the form:
LOGOUT Personid.Projectid {int|abs|dmn|opr} Channel (reason).
In the examples above, "int" refers to interactive logins, "abs"
to absentee logins, "dmn" to daemon logins, and "opr" to operator
logins.
Note that there is not necessarily a process associated with the
LOGIN/LOGOUT audit records. For instance, if a user logs in, and
is told that he has disconnected processes, he remains in what is
called the "connect loop" until he indicates what is to be done.
The state field, which indicates the nature of the login,
identifies this situation with one of its possible values. The
state field can take on the following values.
* create -- a process has been created and the user connected
to it
* destroy -- user has requested a process be destroyed
* connect -- user has connected to a disconnected process
* request -- user has entered the "connect loop"
* new_proc -- user has requested a new process
* dial -- user has issued the dial preaccess command
* slave -- user has issued the slave preaccess command
The "dial" and "slave" preaccess command will only produce a
LOGIN record when the system has enabled the "slave_dial" access
control flag in the CMF.
By examining the LOGIN records, a system administrator can
determine exactly what the system performed on behalf of the user
immediatedly after identification and authentication.
The LOGOUT records include a "reason" field. These typically
will take on the value "logout" or "hangup", but can denote more
esoteric causes for unexpected logouts.
If a user fails to be identified and authenticated correctly, an
entry will be made in the log of te form:
LOGIN FAILED Personid.Projectid {int|abs|dmn|opr} Channel
(reason)
Whenever a process is manipulated by a user, an entry will be
made in the log. Examples include:
CONNECT Personid.Projectid Channel ProcessId
CREATE Personid.Projectid Channel ProcessId
MTB-698 Multics Technical Bulletin
Answering Service Auditing
DESTROY Personid.Projectid Channel ProcessId (reason)
DISCONNECT Personid.Projectid Channel ProcessId (reason)
The reason field, above, will usually be "hangup", or "logout".
In order that the operations staff not be inundated by messages
when a user logs in, these messages (CONNECT, CREATE, DESTROY,
DISCONNECT) will not be routed to the message coordinater
terminal unless they ocurred as a result of a "connect loop"
request. If the request occurred as a result of a login line
control argument, the "state" field on the LOGIN message will be
sufficient for the operations staff to know what is going on.
These messages will always be logged, however.
Messages associated with the "dial" and "slave" preaccess
commands will appear in the log as entries such as the following:
DIAL Channel {Personid.Projectid} to Qualifier
(Personid.Projectid)
SLAVE Channel {Personid.Projectid}
The first instance of "Personid.Projectid" in the above example
will only be available if the site has enabled the CMF
"slave_dial check_acs" flag which results in all "dial" and
"slave" request's being authenticated. The second
Personid.Projectid in the DIAL audit entry refers to the process
to which the user has dialed.
4.4.1 BINARY DATA IN I&A RECORDS
The text portion of the Answering Service Identification and
Authentication (I&A) log entries will change as described in the
previous section. All LOGIN/LOGOUT,
CREATE/DESTROY/CONNECT/DISCONNECT, and DIAL/SLAVE I&A log
entries, will have a binary portion as well. The binary data
will contain security-related attributes of the logged event.
For logins, for example, the following information will be
included in the binary data:
- authorization range (PNT/SAT/CDT/PDT factored in)
- authorization (default or as specified with -auth)
- flags (anonymous, proxy, process type)
- communications channel name
- terminal type
- answerback
- userid/projectid
- audit flags
- min, max, selected ring
- session uid
Multics Technical Bulletin MTB-698
Answering Service Auditing
For process creation, destruction, connection, disconnection, the
binary data will include, in addition to the above information,
the process-id.
DIAL log entries will include process/channel information.
All I&A-related log entries will include a UID associated with
the login session so that administrators can use the log tools to
determine exactly what I&A-type operations a given authenticated
session performed.
4.5 Auditing Communications Channel Usage
The audit messages currently produced by the answering service
program "dial_ctl_" will be restructured to include
security-relevant information in the binary data portion of the
log entries. This information will include:
- communications channel name
- communications channel AIM range
- userid/projectid
- process authorization
- process ring
Currently, the audit messages (text-only) have no syntactic
symmetry. Because of this, they are difficult to follow and
correlate with one another. As part of the answering service
audit effort, these messages will be made more consistent with
one another in terms of syntax and binary content.