Multics Technical Bulletin                                MTB-698
Answering Service Auditing

To:       Distribution

From:     Eric J. Swenson

Date:     01/09/85

Subject:  B2 Answering Service Auditing Changes


     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


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.


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

3.2 Authorization Changes in the PNT Have No Effect on Logged-in

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

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

    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);


   is a standard sys_log_ severity
   is the caller on whose behalf the message is logged
   pointer to binary data
   length of binary data (in words)
   arbitrary character string identifier used by the expansion

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

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

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


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