top - download
⟦26a8f4e12⟧ Wang Wps File
Length: 139892 (0x22274)
Types: Wang Wps File
Notes: SW DESCRIPTION
Names: »4529A «
Derivation
└─⟦57fb8c09c⟧ Bits:30006028 8" Wang WCS floppy, CR 0392A
└─ ⟦this⟧ »4529A «
WangText
C…05…C…07…B…0f…B…00…A…09…A…0c…A…0e…A…05…@…0b…@…01…@…06…?…08…?…0a…?…0c…?
>…09…>…0e…>…00…>…07…=…0f…=…06…<…0f…<…05…;…0b…;…01…:…09…:…0f…:…07…9…0d…9
8…09…8…0e…8
7…09…7…0e…7…00…7…07…6…01…5…0b…5…02…5…07…4…0c…4…02…3…08…3…0e…3
3…06…2…08…2…0a…2…0c……86…1
…02… …02…
…02… …02…
S/W SPECIFICATION
SYS/84-01-04
Page
#
B [ R G E…01……01…dette er kun en del af det samlede v`rk,…01…men man er ikke n>et l`ngere endnu.…01……01…Anne
Marie…01…1984-01-23
Anne Marie, Dette dokument er en kopi af 4460A. S>
hvis dette k]rer ok, bedes I slette 4460A.
STANDARD S/W DESCRIPTION
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
Page
1. INTRODUCTION ..........................
2. SYSTEM SOFTWARE .......................
3. SUPPORT SOFTWARE ......................
4. APPLICATION SOFTWARE ..................
1̲ ̲ ̲I̲N̲T̲R̲O̲D̲U̲C̲T̲I̲O̲N̲
The complete software implementation comprises:
o A Multi-level Security Policy
o System Software
o Support Software
o Application Software.
The multi-level security policy ensures that data,
labeled according to the appropriate level of classification,
can neither be disclosed to unauthorized users nor
be modified by them.
The system software controls the resources of the computer
system and provides support for using these resources.
to implement the multi-level security policy, there
are 16 priviledge levels of execution.
The support software, which is not part of the operational
system, includes the development operating system,
maintenance and diagnostic programs, and system generation
software.
The application software packages implement the functional
capabilities of the system. These packages operate
in the environment provided by the system software,
thus effecting the multi-level security policy as an
integral part of the functional capabilities of the
overall system.
Figure 1-1 contains a functional block diagram of the
system, identifying the principal application packages
and their relationships to system software packages.
From inspection of this diagram it is obvious that
the support software environment encompasses the application
software and ensures implementation of the multi-level
security policy.
In the discussion to follow a detailed description
of each aspect of the software implementation is given.
First, the system software is presented, and then the
multi-level security policy, which is effected by the
system software, is explained. After that, the support
software facilities are listed. Finally, the project
dependent application software is described.
SYSTEM FUNCTIONAL DIAGRAM
A multi-level security policy is ensured by
the system software environment
Figure 1-1
2̲ ̲ ̲S̲Y̲S̲T̲E̲M̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
The CR80 Distributed Advanced Multi-processor Operating
System (DAMOS) is the standard operating system for
the memory mapped CR80 series of computers, and includes
a virtual memory operating system kernel. DAMOS is
particularly well suited for use in real time systems,
although it also supports environments for software
development and batch operation.
DAMOS supports the full range of the CR80 series of
computers from a configuration with a single Processing
Unit (PU) with 1 CPU and 128 K words of random access
memory up to the maximum multi-processor configuration
with 16 PUs - each PU containing 5 CPUs - and 16 M
words of virtual memory. Configurations with multiple
PUs can provide, in addition to extended processing
power, a costeffective fault-tolerant architecture
based on N + 1 redundancy. The flexible architecture
of the CR80 also allows interfacing to a virtually
unlimited amount of peripheral equipment and mass storage.
To accomplish its design goals in an efficient manner,
DAMOS is implemented by a hierarchy of modules, each
dedicated to a special task. At the top of this hiearchy,
the DAMOS kernel provides resource management of, for
example, PUs, CPUs, and memory. Then, other levels
of DAMOS provide process management and inter-process
communication. Finally, to simplify system input/output
and storage, DAMOS provides a well defined, standard
environment for management of files, magtapes, terminals,
and databases.
Multi-level security is an integral part of the DAMOS
design, and the Reference Monitor Concept - a concept
whereby all objects can only be referenced indirectly
with access control according to both mandatory and
discretionary rules - is part of the standard environment
that always encompasses the user/
application software.
Thus, DAMOS provides a secure and efficent system software
environment that supports an extremely flexible computer
architecture.
Detailed descriptions of major DAMOS modules are given
in the sub-sections to follow:
o Kernel
o Input/Output
o System Initialization
o System Status and Control
o Additional System Functions
For reference, an overview of the principal DAMOS modules
- both operational and support modules - is given in
Figure 2-1.
DAMOS SOFTWARE OVERVIEW
A secure and efficient operating system environment
is provided for the full range of the CR80 computer series
Figure 2-1
2.1 D̲A̲M̲O̲S̲ ̲K̲E̲R̲N̲E̲L̲
The DAMOS Kernel, which is a set of re-entrant program
modules that provide the lowest level of system service
above the level of CR80 hardware and firmware, exists
in one incarnation for each PU.
The Kernel consists of the following components:
- Resource Management,
which administers resources in a coherent way
- Directory Function,
which provides a common directory service function
for other Kernel components. Also controls access
to all objects from the other modules.
- Process Manager,
which provides tools for CPU management, process
management and scheduling
- Page Manager,
which provides memory management tools and implements
a segmented virtual memory
- Process Communication Facility,
which provides a mechanism for exchange of control
information between processes
- Device Manager,
which provides a common set of device related functions
for device handlers and a standard interface to
device handlers
- Device Handlers,
which control and interface to peripheral devices
- Error Processor,
which handles errors detected at the hardware and
Kernel level and provides a general, central error
reporting mechanism
- Real Time Clock
for synchronization with real time
- PU Manager,
which provides functions for coupling and decoupling
PUs
- Basic Transport Service,
which provides a general mechanism for exchange
of bulk data between processes and device handlers.
The following sub-sections describe the main Kernel
functions:
- resource management
- process management
- memory management
- process communication
- CPU management
- PU management
- Transport Mechanisms.
2.1.1 R̲e̲s̲o̲u̲r̲c̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The DAMOS Resource Management Function provides a set
of tools to enable individual DAMOS modules to handle
resources in a coherent way, and to resolve conflicts
due to a temporary shortage of resources.
The principles of DAMOS resource management can be
summarized as follows:
o Resources are allocated and de-allocated on a process
basis.
o A process draws its resources from a pool.
o Each process is allowed to use only a specified
maximum number of resources from the pool.
o The resources associated with a pool may be used
exclusively by one process, or they may be shared
by several processes.
o A process may create a new pool for its subordinate
processes, drawn from its own pool.
o When a process is created, its parent process specifies
the pool from which it can draw its resources.
This may be the pool of the parent process, a private
pool created for the child process, or a pool shared
with other child processes.
2.1.2 P̲r̲o̲c̲e̲s̲s̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
Process management is concerned with both long and
short term control of processes. In the long term,
a process can have three states: undefined, active,
and inactive. Figure 2.1.2-1 illustrates these states
and gives the process management functions, available
to the user, which result in state transitions. Brief
definitions of key process management functions are
given below.
CREATE PROCESS intiates a new process instance to run
on a specific processor pool. The new process is given
access to specified resource pools, and inherits a
set of object descriptors at the discretion of the
creator. The new process does not get execution time
before its parent process calls Resume Process.
RESUME PROCESS activiates a process which was either
just created or was previously passivated.
PASSIVATE PROCESS deactivates a process, i.e. the process
is temporarily withdrawn from the dispatching
CLEAN UP PROCESS catches a child process and terminates
its activities. Among other things, its possible child
processes are cleaned up and deleted, and outstanding
process activities (I/O requests, process communication)
are cancelled.
DELETE PROCESS removes a previously cleaned process
from the system. The resources occupied by the process
are returned to the caller (its parent process)
RETIRE passivates the caller and sends possible error
information to its parent process.
GET PROCESS ATTRIBUTES returns the current attributes
of a child process
CHANGE PROCESS ATTRIBUTES changes specified attributes
of a child process. The attributes may relate to the
dispatching of the process (e.g. its priority), or
to the page manager parameters for the process (e.g.
the size of its working set).
In DAMOS, a process - the parent may create subordinate
processes - child processes. This allows creation of
a process hierarchy which enables implementation of
"multiple" operating systems, each haveing supreme
control over its child processes. Figure 2.1.2-2 gives
an example of process hiearchy in DAMOS.
Processes belonging to an operating system, i.e. parent
process, compete for system resources such as processor
power, physical memory, and I/O services. To administer
the limited resources that are available, a process
in the active state is subject to short term scheduling
(dispatching) as illustrated in Figure 2.1.2-3.
1: The process is subject to CREATE PROCESS
2: The process is subject to DELETE PROCESS
3: The process is subject to RESUME PROCESS
4: The process is subject to PASSIVATE PROCESS
or
RETIRE
Figure 2.1.2-1
LONG TERM PROCESS MANAGEMENT
parent process
child processes
DAMOS PROCESS HIERARCHY
Allows implementation of multiple operating systems.
Figure 2.1.2-2
1: The process is scheduled by the dispatcher
2: The process is preempted by the dispatcher
3: The process is blocked awaiting some event
4: A previous awaited event occurs
SHORT TERM PROCESS MANAGEMENT
Ensures access to limited resources.
Figure 2.1.2-3
2.1.3 M̲e̲m̲o̲r̲y̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The DAMOS Page Manager implemtns a virtual memory concept
that allows each process to access any part of the
CR80 physical memory - up to the configuration maximum
of 16 M words. At any one time, however, the CR80 addressing
mechanism limits the address space "seen" by a process
to a maximum window of 2 x 64 K words.
Segments of virtual memory may be created and deleted
by a process, i.e. ownership is established. A process
which has created a segment may allow others (subject
to security constraint restrictions) to share the segment
by explicitly identifying the process and stating access
rights to the segment.
2.1.4 P̲r̲o̲c̲e̲s̲s̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
Exchange of data between processes is effected by means
of synchronization (sync) elements, which implement
logical data transfer. Sync elements may be known locally,
throughout parts of the computer system, or on a system-wide
basis. Thus DAMOS provides a flexible communication
facility for implementing inter-process communication
subject to security constraints.
2.1.5 C̲P̲U̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The CPUs (1-5) that are physically located in a PU
may be either treated as a resource pool for all processes
running in the PU or divided into pools that are allocated
to one or more processes. Thus a PU can be configured
as a set of resources running under one operating system
or a host for multiple operating systems. In the case
of multiple operating systems, it is possible, of course,
to dedicate one or more of the CPUs to one process.
2.1.6 P̲r̲o̲c̲e̲s̲s̲i̲n̲g̲ ̲U̲n̲i̲t̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The DAMOS Kernel provides facilities for managing the
logical connections between the individual Processing
Units attached to a Supra Bus. PUs may be connected
logically into groups, and the number of PUs in a group
may vary from 1 to 16. Two groups may be merged, the
result being a new PU-group.
Objects are identified by symbolic names having either
local or global scope, and they are accessible from
all PUs in the group where they reside.
PU Management is designed to allow graceful degradation
whether purposely closing a PU or isolating a faulty
PU. It is possible for a PU to force another member
out of their common group. All PUs in the group are
informed to break their logical connection to the designated
PU. As a consequence all global objects residing in
the isolated PU are thereafter unknown to the group.
If not faulty, the isolated PU continues executing
its local processes and is ready to receive new include
requests.
Basic Transport Service (BTS) is a module within DAMOS
which enables processes to communicate in a uniform
manner. The processes may be located in:
1) the same CR80 processor unit
2) computers connected via a supra bus, running
under the same operating system
3) computers connected via a communication line,
running under independent operating systems.
2.2 D̲A̲M̲O̲S̲ ̲I̲N̲P̲U̲T̲/̲O̲U̲T̲P̲U̲T̲ ̲S̲Y̲S̲T̲E̲M̲
DAMOS supports user program input/output by providing
a set of standard interface procedures through which
a user communicates with a class of DAMOS service processes
known as General File Management Systems. General
File Management Systems (GFMS) include:
- the File Management System which implements disk
files
- the Magnetic Tape File Management System for magnetic
tape files
- the Terminal Management System for communication
lines, interactive terminals and printers.
- The Database Controller System for communication
with the Database Management System.
The General File Management Systems provide functions
which are classified as:
- device handling
- user handling
- file handling
- file access.
The common file access functions provided by the IOS
are readbytes for input and appendbyte and modifybytes
for output.
These basic functions are used for transfer of blocks
of data. On top of these functions the IOS provides
a stream I/O facility where the IOS handles the blocking
and buffering of data. The relationship of the application
program, the IOS, and the GFMS is shown in Figure 2.2-1.
DAMOS IOS
provides a user frindly interface between the
application program and the General File Management System
Figure 2.2-1
2.2.1 F̲i̲l̲e̲ ̲M̲a̲n̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲ ̲(̲F̲M̲S̲)̲
The FMS provides a clearly defined interface for storing,
maintaining, and retrieving data on disc storage devices.
The number and kind of devices attached to the FMS
is dynamically reconfigurable. All accesses via FMS
by user processes are subject to security constraints.
The following FMS aspects are described in detail in
the sub-sections to follow:
a) devices and volumes
…02…b) directories
c) files
d) users
e) file security
f) disc integrity
g) access methods
h) message management system.
a) D̲e̲v̲i̲c̲e̲ ̲a̲n̲d̲ ̲V̲o̲l̲u̲m̲e̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
The file system may be given commands concerning:
Management of peripheral devices: Devices can be
assigned to and deassigned from the file system
dynamically. Instances of device handlers are
at the same time created or deleted.
Management of volumes: Volumes can be mounted on
and dismounted from specific devices.
b) D̲i̲r̲e̲c̲t̲o̲r̲i̲e̲s̲
The file system uses directories to implement symbolic
naming of files. If a file has been entered into
a directory under a name specified by the user,
it is possible to locate and use it later on, but
temporary files do not need to be named. A file
may be entered into several directories, perhaps
under different names. Since a directory is also
considered a file, it can itself be given a name
and entered into another directory. This process
may continue to any depth, thus enabling a hierarchical
structure of file names.
c) F̲i̲l̲e̲s̲
The file system supports two different organizations
of files on disc: configuous and random. A contiguous
file consists of a sequence of consecutive sectors
on the disk. The size of a contiguous file is
fixed at the time the file is created and cannot
be extended later on. A random file consists of
a chain of indices giving the addresses of areas
scattered throughout the volume. Each area consists
of a number of consecutive sectors. The number
of sectors per area is determined at creation time,
whereas the number of areas may change during the
lifetime of the file.
File system commands may be divided into 3 groups:
o Creation and removal of files:
A user may request that a file will be created
with a given set of attributes, and put on
a named volume.
o Naming of files in directories:
A file may be entered into a directory under
a symbolic name that then can be used to locate
the file. The file may then be renamed or removed
from the directory again.
o Change of access rights:
The right to change access rights vis …1a… vis
a file for all users or a specific user group
is itself delegatable.
d) U̲s̲e̲r̲s̲
The FMS may be given commands to create or remove
users (processes).
e) F̲i̲l̲e̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲
FMS data security is ensured by two mechanisms:
access control lists (ACLs) and the security classification
policy.
i The ACL is a table which describes the access
rights of each individual user group (one being
the public) to the corresponding file. Whenever
a user tries to access a file, the ACL is used
to verify that he is indeed allowed to perform
this access. There is one ACL associated with
each file.
ii The second mechanism for access control is
based on a security classificatio system.
Each user and each file is assigned a classification.
The user classification is recorded in the
user control block and the file classification
is recorded on the volume. For read access,
the user security level must be greater than
or equal to the file security. For write access,
the user security level must match that of
the file.
Thus the file access security policy implements
distinct levels of security classification
as well as discretionary (need-to-know) security,
i.e. user groups.
f) D̲i̲s̲c̲ ̲I̲n̲t̲e̲g̲r̲i̲t̲y̲
The FMS implements identical (redundant) disc pack,
which are updated concurrently to ensure that data
will not be lost in the case of a hard error on
one of the two discs. When an error does occur,
the FMS permits exclusion of the failed unit, and
normal service continues with the remaining unit.
After repair, it is possible to bring one volume
upto the state of the running volume while normal
service continues, although perhaps with degraded
service during a short period.
With respect to bad sectors on a disc pack, the
FMS handles the problem by keeping a table with
translation from each bad sector to an alternative
sector for each volume. Only failures of sector
0 cannot be handled. While using redundant disks
the translation tables of the two disks must be
kept identical to assure that all disk addresses
can be interpreted in the same way. If bad sectors
are detected while bringing up a disk, they are
marked as such on both disks and both translation
tables are updated accordingly.
g) A̲c̲c̲e̲s̲s̲ ̲M̲e̲t̲h̲o̲d̲s̲
Two access methods to files are implemented by
the FMS: unstructured and endexed sequential.
i For transfer purposes an unstructured file
is considered simply as a string of bytes,
and therefore a byte string is transferred
between a file and a user buffer. The user
can access directly any byte string in a file.
The commands which are implemented by this
access methods are:
READBYTES - Read a specified byte string
MODIFYBYTES - Change a specified byte string
APPENDBYTES - Append a byte string to the
end of the file.
ii The Christian Rovsing Access Method (CRAM)
for indexed sequential file access features
random or sequuential (forward or reverse)
access to records of 0̲ to n bytes, with n depending
on the selected block size, based on keys of
0-126 bytes. The collating sequence uses the
binary value of the bytes so e.g. character
strings are sorted alphabetically. CRAM works
on normal contiguous FMS files which are initialized
for use by means of a special CRAM operation.
The CRAM updating philosophy is based on the
execution of a batch of related updatings,
which all together form a consistent status
change of the CRAM file, being physically updated
as a single update by means of a LOCK operation.
Thus, after a batch of updates, all files updated
may either be forgotten (by means of the FORGET
operation) or changed (by means of the LOCK
OPERATION). Both operations are performed without
producing critical regions, i.e. without periods
of CRAM data base inconsistency.
For convenience, CRAM supports subdivision
of the CRAM file in up to 255 subfiles, each
identified by a subfile identifier key of 0-126
bytes.
CRAM keeps track of the different versions
of the data base by means of a 32 bit version
number, which is incremented every time LOCK
is called.
h) M̲e̲s̲s̲a̲g̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲ (MMS)
The Message Management System contains facilities
for storage of messages and similar items on disk
and manipulation of these messages and items. Each
item is stored in an entity called C̲CIS I̲nformation
F̲ile (CIF). The main difference between a CIF and
an ordinary file is that CIFs are relatively small,
and that they are subject to very intense activity
during a relatively short period after their creation.
After that period they will be stored permanently,
and will be subject to very low activity. MMS will
optimize storage of and access to items according
to the activity level.
2.2.2 M̲a̲g̲n̲e̲t̲i̲c̲ ̲T̲a̲p̲e̲ ̲F̲i̲l̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲ (MTFMS)
The MTFMS is responsible for storing and retrieving
information on magnetic tapes. All access via the MTFMS
by user processes is security checked. Each MEFMS is
able to handle one magnetic tape controller with a
maximum of 8 tape transports in a daisy chain.
The functions of the file system can be separated into
four groups:
o Device Functions
o Volume Functions
o File Functions
o Record Functions.
a) D̲e̲v̲i̲c̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The MTFMS implements two principal device functions:
o Assign a name to a given tape transport unit
o De-assign a given unit.
b) V̲o̲l̲u̲m̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲
The MTFMS implements four principal volume functions:
o Initiate a tape by writing a volume label,
i.e. naming the tape.
Note: symbolic volume names comply with the
ISO 1001 standard.
o Mount a given volume on a given tape transport
unit.
o Dismount a given volume.
o Rewind a given volume.
c) F̲i̲l̲e̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The MTFMS implements five principal file functions:
o Create a file on a given volume. The file is
opened for output, and the given volume is
reserved for the caller. The following information
must be supplied by the caller, and will be
written onto the tape in a file header label
record:
- File name (must comply with ISO 1001 standard)
- Fixed/variable length record specification
- Record size.
o Find a file with a given name on a given volume.
The file is opened for input and the given
volume is reserved.
o Skip a given number of files (backwards or
forwards) on a given volume. The file at the
resulting tape position is opened for input
and the volume is reserved.
o Get information about the currently open file
on a given volume. Information like file sequence
number, record size and type (fixed/variable
length) can be retrieved.
o Close currently open file on a given volume.
The volume reservation is released.
d) R̲e̲c̲o̲r̲d̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
o Skip a given number of records (forwards or
backwards) in a given file.
o Read a record in a given file.
o Write a record in a given file. The MTFMS performs
recovery from writing errors by
- backspacing over the record in error
- erasing a fixed length of about 3.7 inches
(thus increasing the record gap).
- attempting the writing once more.
The recovery procedure will be attempted a maximum
of 10 times.
2.2.3 T̲e̲r̲m̲i̲n̲a̲l̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲ ̲
The TMS is a service process which manages devices
characterized by serial blockwise access. Examples
of such devices are:
- interactive terminals (screen or hardcopy)
- data communication equipment (modems)
- line printers
- card readers
In the following discussion, the phrase "terminal"
is used as a common term for any device of this category.
Terminals may be attached to LTUs, LTUXs (via TDX)
and parallel interfaces.
The TMS performs the following main functions:
- terminal related security validation
(all access via TMS by user processes is security
checked).
- access control for terminals
- collecting of statistical information
- management of terminals
- transfer of I/O data between terminal device
handlers and user processes.
The following subsections define:
- transfer of I/O data
- user handling
- security
- hardware categories.
a) T̲r̲a̲n̲s̲f̲e̲r̲ ̲o̲f̲ ̲I̲/̲O̲ ̲D̲a̲t̲a̲
The TMS enables user processes to perform flexible
I/O communication with terminals. I/O is aimed
at terminals which will be connected to varying
processes with different security profiles. The
terminals in question will normally be local or
remote interactive hardcopy or screen terminals.
I/O to terminals is identical to I/O to backing
store files from the point of view of the user
process. The same IOS basic procedures are used
(appendbytes, modifybytes, readbytes) and direct
as well as stream I/O can be used.
b) U̲s̲e̲r̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
Before a user process can make use of the TMS functions,
it must be logged on to the TMS by means of the
Useron command. This command must be invoked by
a process which is already known by the TMS, either
through another Useron command or because it is
the parent process for the TMS.
In the Useron command the calling process grants
some of its TMS resources to the process which
is logged on to the TMS in the Useron command.
When a user process ceases to use the TMS, its
TMS resources must be released by a call of Useroff.
c) S̲e̲c̲u̲r̲i̲t̲y̲
TMS data security is ensured by two mechanisms:
access control lists (ACLs) and the security classification
policy.
i The ACL is a table which described the access
rights of each individual user group (one being
the public) to the corresponding line. Whenever
a user tries to access a line the ACL is used
to verify that he is indeed allowed to perform
this access. There is one ACL associated with
each line.
ii The second mechanism for access control is
based on a security classification system.
Each user and each line is assigned a clasification.
The user classification is recorded in the
user control block and the line classification
is recorded in the line control block. Classification
levels of the user and the line must match
each other.
d) H̲a̲r̲d̲w̲a̲r̲e̲ ̲C̲a̲t̲e̲g̲o̲r̲i̲e̲s̲
The TMS recognizes the following categories of
equipment:
- T̲e̲r̲m̲i̲n̲a̲l̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲ which is a line controller
interfacing one or more lines.
- L̲i̲n̲e̲ which is a group of physical signals
capable of sustaining one simplex or duplex
data stream.
- U̲n̲i̲t̲ which is a terminal device connected
to a line.
If more than one unit is connected to a given line,
the line is called multiplexed line.
o T̲e̲r̲m̲i̲n̲a̲l̲ ̲C̲o̲n̲t̲r̲o̲l̲l̲e̲r̲s̲
Terminal controllers may dynamically be assigned
and deassigned by the parent process for the
TMS.
A controller can either be assigned as an active
or as a stand-by controller. A stand-by controller
is a device which normally is not active, but
which may take over in case of a failure in
an active controller.
When an active controller is assigned with
a stand-by, this must be defined in the assignment
command.
The process which assigned a controller is
its initial owner. Ownership of a controller
may be transfered to another user process which
is logged on to the TMS. When a controller
is assigned, the TMS creates a corresponding
device handler.
o L̲i̲n̲e̲s̲
The owner of a controller may assign lines
to the controller. When a line is assigned,
the TMS notifies the device handler for the
controller to that effect.
o U̲n̲i̲t̲s̲
The owner of a controller with lines assigned
to it may create units on the lines. Units
can be created for file mode I/O or communication
mode I/O. A unit created for file I/O may be
a multiple or single access unit. Single access
units can only be accessed by the owner whereas
multiple access units may be accessed by a
number of user processes.
When the owner creates a unit, an access path
to the unit is established. The owner may from
now on access the unit by the IOS functions
readbytes for input - and appendbytes, and
modifybytes for output. Other users may obtain
access to a multiple access unit in different
ways as described in the following.
The creator of a unit may offer it to another
user by means of the TMS OFFER function. The
user to which the unit is offered obtains access
to the unit by the ACCEPT function.
The creator of a unit may define a symbolic
name - a unit name - for the unit. A unit name
is syntactically identical to an FMS file name.
Other users may obtain access to the named
unit by the LOOKUP ̲UNIT command which corresponds
to the FMS commands getroot, lookup and descent.
2.2.4 D̲a̲t̲a̲b̲a̲s̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲S̲y̲s̲t̲e̲m̲ ̲(DMCS)
The DMCS package is the interface between the DBMS
package and the packages using DBMS. Two key aspects
of the DMCS are protocol handling and security.
o D̲B̲M̲S̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲ ̲P̲r̲o̲t̲o̲c̲o̲l̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲
The interface protocol is used to transmit requests
and parameters from requesting processes to DBMS
and to receive the response data. In addition to
the request, the necessary control information
about the requesting process is transmitted. The
DBMS must keep track of the number of pending requests
from processes.
o S̲e̲c̲u̲r̲i̲t̲y̲
Requests from processes are checked before they
are transmitted to the DBMS. For each process only
a subset of the DBMS functions are legal, and requests
are denied if they do not belong to the legal subset.
Together with the request, the following security
information is sent to DBMS:
- Security Attributes of the process.
- Process Identification of the process.
Each request to DBMS is logged on the security
audit by DMCS. The security information is supplied
by the SSC package whenever it creates a process.
The SSC is described in section 2.4.
2.3 S̲Y̲S̲T̲E̲M̲ ̲I̲N̲I̲T̲I̲A̲L̲I̲Z̲A̲T̲I̲O̲N̲
When a CR80 memory mapped PU is master cleared, a boot
strap loader is given control. The boot strap loader
is contained in a programmed read-only memory which
is part of the MAP module. Having initialized the translation
tables of the MAP module, the boot strap loader is
able to fetch a system load module from a disk connected
to the PU.
An initialization module which is part of the load
module initalizes the DAMOS kernel and the DAMOS Root
process.
The Root process possesses all the PU resources. Root
creates and intializes a File Management System, a
Terminal Management System and a System Status and
Control System.
2.4 S̲Y̲S̲T̲E̲M̲ ̲S̲T̲A̲T̲U̲S̲ ̲A̲N̲D̲ ̲C̲O̲N̲T̲R̲O̲L̲ (SSC)
The SSC package starts, allocates resources to, and
monitors and controls on-line and off-line systems
through interaction between the two PUs, the peripherals,
the watchdog, and the operator.
The on-line modes of operation handled are:
- a dualized system consisting of one active PU and
associated peripherals and a stand-by PU
- a degraded system consisting of one active PU and
associated peripherals and an off-line PU and associated
peripherals
In the degraded system the SSC controls the off-line
operations:
- software development and test
- table generation
- maintenance and diagnostics
- offline utilities
The monitoring of the active and the standby system
includes:
- reception of error reports from other packages
- reception of hardware status from crates
- display of system status
- execution of on-line diagnostics programs
The control of the dualized and degraded system includes:
- physical connection of hardware modules
- allocation of resources to other packages e.g.
external and terminal lines
- execution of operator commands
The start-up of the dualized and degraded system includes:
- all forms of initialization
- ordered switchover to a stand-by processor and
corresponding recovery and restart actions
- recovery/restart actions during an emergency switchover
or after a total system error
The sub-sections to follow describe
i) On-line diagnostics
ii) Line monitoring and control
iii) Handling of technical error reports
iv) On-line PU operator commands
v) Off-line PU operation.
i) O̲n̲-̲L̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲s̲
Generally the on-line diagnostics test programs
aim at limiting the effect of an error by
- timely detection of errors
- reporting the error condition
Specifically the test programs participate in meeting
the availability and integrity of operation requirements.
The test programs operate as low priority tasks together
with the application software. A specific test program
to verify system integrity through a checksumming of
read-only system software is available. The program
is executed on request from the system management and
periodically.
ii) L̲i̲n̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲
Line Monitoring and Control are divided into four
areas:
- Terminal Monitoring and Control (TEMCO)
- Device Monitoring and Control (DEMCO)
- Circuit Monitoring and Control (CEMCO)
- Watchdog Monitoring and Control (WAMCO)
a) T̲e̲r̲m̲i̲n̲a̲l̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲T̲E̲M̲C̲O̲)̲
TEMCO monitors and controls LTU lines to Alphanumeric
and Graphic Terminals.
The TEMCO functions are divided into three areas:
- Execution of logical control on behalf of other
packages e.g. access control.
- Monitoring of connections to the terminals
and subsequent execution of control
- Device handling control processes.
The control includes the user initiated events:
- sign on/off
- specification of functional capabilities and
security attributes
- transaction handling
- error reports
b) D̲e̲v̲i̲c̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲D̲E̲M̲C̲O̲)̲
DEMCO monitors and controls LTU lines to Stand
Alone Devices
The stand alone devices handled are:
- Line Printers
- X-Y Plotters
- Digitizers
- PTR, PTP
The DEMCO functions are divided into three areas:
- Execution of logical control on behalf of other
packages e.g. access control
- Monitoring of connections to the SADs and subsequent
execution of control.
- Start and Retire Device Handling Control Processes
c) C̲h̲a̲n̲n̲e̲l̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲C̲E̲M̲C̲O̲)̲
CEMCO monitors and controls LTU lines to External
Circuits.
The Circuits handled are
- NICS-TARE
- X ̲25 protocol circuits
The CEMCO functions are divided into three areas:
- Execution of logical control on behalf of other
packages e.g. access control (accept/non accept
of input on a line)
- Monitoring of the connection to the EXCs and
subsequent execution of control.
The monitoring includes the reception of error
reports.
- Start and Retire Circuit Protocol Processes.
d) W̲a̲t̲c̲h̲d̲o̲g̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲(̲W̲A̲M̲C̲O̲)̲
The WAMCO functions include
- sending of keep-alive messages from active/standby
PUs to the watchdog.
- monitoring of the WDP, WDP-VDU and WDP-ROP
physical state
and subsequent actions, which may be
- reinsertion of a device
- handling of a WDP ̲VDU connected directly
to the PU
- display the WDP ̲ROP paper out condition at
the WDP ̲VDU configuration display
- reception of monitoring information from the
WDP.
iii) H̲a̲n̲d̲l̲i̲n̲g̲ ̲o̲f̲ ̲T̲e̲c̲h̲n̲i̲c̲a̲l̲ ̲E̲r̲r̲o̲r̲ ̲R̲e̲p̲o̲r̲t̲s̲
This section covers error handling in general and includes
the following topics:
- error detection
- error types
Technical errors are detected during:
- System calls or asyncronously
- Instruction execution
- Validity checks
- WDP monitoring
Errors detected during system calls have one of the
following types:
- SW errors:
- resource error
- security violation
- illegal parameter error
- informative completion code
- HW errors:
- TMS connection error
- FMS connection error
- CESE error (Central error reporting synchronization
element)
iv) O̲p̲e̲r̲a̲t̲o̲r̲ ̲C̲o̲m̲m̲a̲n̲d̲s̲ ̲t̲o̲ ̲a̲n̲ ̲O̲n̲-̲L̲i̲n̲e̲ ̲P̲U̲
Operator commands control the CCIS hardware and software
configuration. The execution of the control is shared
between the SSC in the active PU and the WDP. The SSC
in the active PU directs in the WDP to execute hardware
control.
The basis for execution of operator commands is status
information displayed on the operator VDU and detailed
error reports printed at the operator printer.
The following types of operator functions are foreseen:
- start-up of all modes of the system
- ordered close down of the system
- switch-over from Active PUs to the Standby PU
- device control
- connection of devices to buses
- enable/disable operational use of a device/line
- control of line attributes (e.g. speed)
- load of new software
- print of software versions
- define generation of trace information
- print system status
- adjust time
- commands directly to the watchdog
iv) O̲f̲f̲-̲L̲i̲n̲e̲ ̲P̲U̲ ̲O̲p̲e̲r̲a̲t̲i̲o̲n̲
The SSC provides a command interface to the support
software package (SSP) and the offline package (OLP)
in the off-line PU and allocates resources to enable
the off-line operations.
The SSP commands includes low level M&D (maintenance
and diagnostic) commands to the MAP and MIA (MAP interface
processor).
2.5 C̲C̲I̲S̲ ̲S̲Y̲S̲T̲E̲M̲ ̲F̲U̲N̲C̲T̲I̲O̲N̲S̲
CSF is a system software package which on top of KERNEL
supplies a set of support tools for application packages.
The main groups of functions are:
a) Shared Buffer Management
b) Timer Facilities
c) Queue Handling
d) Message Management System Interface Facilities
e) General System Call and Multi-Tasking Facilities
2.6 D̲A̲T̲A̲B̲A̲S̲E̲ ̲M̲A̲N̲A̲G̲E̲M̲E̲N̲T̲ ̲S̲Y̲S̲T̲E̲M̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
To support the CCIS Database and meet the requirements
of the RFP, this Contractor proposes the use of the
Britton Lee Inc. Intelligent Database Machine (IDM-
500). This specialized hardware database provides the
capabilities requested in the RFP with the capability
increasing the database size by a factor of 10 and
increasing the processing speed of the IDM by an overall
factor of 2.
The IDM 500 is a relational database. Although the
relational data model is relatively new, it has been
acclaimed as the most flexible and elegant of the data
models. Because it is based on a rigorous mathematical
structure, its data can be easily described and accessed.
Until there was hardware designed specifically to perform
relational DBMS functions, however, it appeared that
relational database systems would not be fast enough
to be commercially viable. Relational DBMS Systems
implemented as software running on a host under control
of a general-purpose operating system are plagued with
performance problems. The IDM satisfies the high performance
criteria of DBMS systems while offering all the benefits
of the relational data model.
The IDM relational database management system organizes
data into one or more independent databases. Each database
is a collection of tables referred to as "relations".
Generally all of the relations in one database contain
logically related information.
T̲A̲B̲L̲E̲ ̲O̲F̲ ̲C̲O̲N̲T̲E̲N̲T̲S̲
Page
3.7 SECURITY .................................
3.7.1 Security Assurance Via Hardware ........
3.7.1.1 Principal Hardware Architecture ....
3.7.1.2 Memory Mapping .....................
3.7.1.3 CPU States .........................
3.7.1.3.1 Instruction Execution ..........
3.7.1.4 MONitor Instruction ................
3.7.1.5 Interrupts .........................
3.7.1.5.1 External Interrupts ............
3.7.1.5.2 Internal Interrupts ............
3.7.1.5.3 Interrupt Handling ............
3.7.1.6 Integrity Checks ...................
3.7.1.6.1 Passive Checks .................
3.7.1.6.2 Active Checks ..................
3.7.1.7 Configuration Control ..............
3.7.1.8 Packaging and Cabling ..............
3.7.1.8.1 Equipment in EMI-racks .........
3.7.1.8.2 Selfstanding peripherals and -
terminals ......................
3.7.2 Security Assurance via Software ........
3.7.2.1 Summary ............................
3.7.2.2 Terminal Security ..................
3.7.2.2.1 Objectives .....................
3.7.2.2.2 Man Machine Interface ..........
3.7.2.2.2.1 Security Attributes ........
3.7.2.2.2.2 Initiation and Termination..
3.7.2.2.2.3 Security Attributes of
Users and Terminals ........
3.7.2.2.3 Authentication .................
3.7.2.2.4 Sign On ........................
3.7.2.2.5 Sign Off .......................
3.7.2.2.5.1 Sign Off Command ...........
3.7.2.2.5.2 Automatic Sign Off .........
3.7.2.2.5.3 Terminal Blocking ..........
3.7.2.2.6 Security Split .................
3.7.2.2.6.1 Security Attributes Line ...
3.7.2.2.6.2 Security Command/Response...
3.7.2.2.7 Change of Password .............
3.7.2.2.8 Relation to Security Model .....
3.7.2.3 Data Base Security .................
3.7.2.3.1 Summary ........................
3.7.2.3.2 Data Base Objects ..............
3.7.2.3.3 Security Functions of
Data Base Management System ....
3.7.2.3.3.1 View .......................
3.7.2.3.3.2 Mandatory Acces Control ....
3.7.2.3.3.3 Discretionary Access Control
3.7.2.3.4 Security Functions of Data
Base Monitoring and Control ....
3.7.2.3.5 Additional Integrity Checks ....
3.7.2.3.6 Assurance of Data Base
Management System Software .....
3.7.2.4 Security Audit .....................
3.7.2.4.1 Objectives .....................
3.7.2.4.2 Auditing Events ................
3.7.2.4.2.1 Terminal Activities ..........
3.7.2.4.2.2 Communication Lines ........
3.7.2.4.2.3 Local Devices ..............
3.7.2.4.3 Protection of Auditing Data ....
3.7.2.4.4 Audit Trail Analysis ...........
3.7.3 Security Assurance of the
Integrated System ......................
3.7.3.1 Summary ............................
3.7.3.2 Systems Architecture ...............
3.7.3.2.1 Summary ........................
3.7.3.2.2 DAMOS Operating System .........
3.7.3.2.2.1 DAMOS Functions ............
3.7.3.2.2.1.1 Kernel Functions .......
3.7.3.2.2.1.2 General File Management
…02… System .................
3.7.3.2.2.1.3 System Status and
Control...............
3.7.3.2.2.2 Process Concept ............
3.7.3.2.2.3 Object Concept ...........
3.7.3.2.2.3.1 Access to Objects ......
3.7.3.2.2.3.2 Object Types .........
3.7.3.2.2.3.3 Logical Object Level .
3.7.3.2.2.4 Memory Protection .........
3.7.3.2.2.4.1 Views ..................
3.7.3.2.2.4.2 Process Layout ...........
3.7.3.2.2.4.3 System Mode and System
and Levels............
3.7.3.2.3 Trusted Computer Base Software...
3.7.3.2.3.1 Security Kernel .............
3.7.3.2.3.2 Trusted System Processes ....
3.7.3.2.3.3 Trusted Utilities ...........
3.7.3.2.3.4 Trusted Application Processes
3.7.3.2.4 Protection and Encapsulation
of Trusted Computer Base ........
3.7.3.2.4.1 Protection of TCB against
Nontrusted Software ...........
3.7.3.3.2 Internal Separation of TCB Modules
3.7.3.2.5 Security Model ..................
3.7.3.2.5.1 Object ......................
3.7.3.2.5.2 Security Attributes .........
3.7.3.2.5.3 Access Control ..............
3.7.3.2.5.3.1 Mandatory Access Control
3.7.3.2.5.3.2 Discretionary Access
Control .................
3.7.3.2.5.3.3 General Access Control
3.7.3.2.6 Enforcing Security or
Untrusted Software ............
3.7.3.3 Covert Channel Analysis .............
3.7.3.3.1 Covert Storage Channels .........
3.7.3.3.2 Timing Channelse ................
3.7.3.3.3 Conclusion ......................
3.7.3.4 MAPPING SECURITY ....................
3̲ ̲ ̲S̲E̲C̲U̲R̲I̲T̲Y̲
3.7.1 S̲e̲c̲u̲r̲i̲t̲y̲ ̲A̲s̲s̲u̲r̲a̲n̲c̲e̲ ̲V̲i̲a̲ ̲H̲a̲r̲d̲w̲a̲r̲e̲
3.7.1.1 P̲r̲i̲n̲c̲i̲p̲a̲l̲ ̲H̲a̲r̲d̲w̲a̲r̲e̲ ̲A̲r̲c̲h̲i̲t̲e̲c̲t̲u̲r̲e̲
The principal hardware architecture is shown on figure
3.7.1-1. The principal components are:
- PU RAM
The main memory of the system. It is only accessible
by the CPU's and only via the MAP. The PU RAM consists
of up to 2M words of 16 bits.
- CPU
Up to 5 central processes units.
CPU's may access PU RAM, CU RAM and Peripheral
Processors via MAP.
- Peripheral Module
A peripheral module controls a device or a set
of similar devices (disks, communication lines
etc.)
It consists of CU RAM and a Peripheral Processor.
- CU RAM
Random access memory in a peripheral module. It
can be accessed by the MAP and by the peripheral
processor in the same peripheral module. CU RAM
may add up to 14 M words of 16 bits.
- Peripheral Processor.
A processor controlling a device or a set of devices.
It can access the device(s) and the CU RAM in the
same peripheral module, and it can send interrupt
signals directly to MAP.
- MAP
The memory mapping unit controls CPU access to
PU RAM, CU RAM and peripheral processor, and it
interrupts CPU's on request from peripheral processors.
From a security point of view it should be noted that
each peripheral processor can only access its own local
CU RAM, and that all memory accesses from CPU's are
mediated by the MAP.
3.7.1.2 M̲e̲m̲o̲r̲y̲ ̲M̲a̲p̲p̲i̲n̲g̲
The total physical address space is up to 16M words
of 16 bits, while the logical address space of a CPU
is at any time confined to 64K words of program space
and 64K words of data space.
The memory mapping unit is responsible for mapping
of logical addresses onto physical ones and for check
of access rights to memory locations.
The principles of memory mapping is shown on figure
3.7.1-2.
Memory is divided into pages of 1K words of 16 bits.
The mapping of the logical address space of a CPU requires
two translation tables (TT) in the MAP, the program
translation table and the data translation table. Each
TT consists of 64 entries.
A TT entry contains of two fields:
- physical page number, specifying a page of 1K words
in PU or CU RAM.
- access rights
The access rights field of a TT entry can have 4 different
values:
0: Page Absent
There is no physical memory page corresponding
to this logical page.
1: Read Access
This means read access in user state and read/write
access in system state.
2: Full Access
This means read/write access in both user and system
state.
3: No Access
This means no access in user state and read/write
access in system state.
The MAP contains 32 pairs of TT's. Ten of the pairs
are dynamic ones. They are used to describe the memory
mapping associated with execution of processes. The
remaining ones are static and used to describe the
memory mapping associated with execution of kernel
programs, including device handlers.
In addition to the memory protection implemented by
the map, the CPU itself implements two protection mechanisms:
- Protection against program modification.
There are no instructions which allow writing into
the logical program space.
- Bound Registers.
In system state a bound register in the CPU limits
write instructions to the part of the data address
space with logical addresses lower than or equal
to the current bound register. There is a separate
bound register for each system level, cf. 3.7.1.3.
The use of the memory protection mechanism is further
described in 3.7.3.2.2.4.
3.7.1.3 C̲P̲U̲ ̲S̲t̲a̲t̲e̲s̲
The CPU may execute in two states:
USER state
SYSTEM state
In the system state the CPU will further be at one
of 15 system levels which are numbered 1 through 15.
In user state, the level is 0.
In U̲S̲E̲R̲ ̲s̲t̲a̲t̲e̲ the CPU is not allowed to execute any
privileged instructions and it is subject to the memory
access protection mechanism of the MAP module.
In S̲Y̲S̲T̲E̲M̲ ̲s̲t̲a̲t̲e̲ the CPU has full access to all locations
within the logical address space.
For those of the instructions which may be executed
on levels 1 to 14, a memory write protection mechanism
based on a BOUND register applies: The CPU only allows
write operations to locations with effective logical
addresses lower than or equal to the current value
of the BOUND register. This mechanism is implemented
in the CPU alone (not involving the MAP module).
The use of system state and bound register is further
described in 3.7.3.2.2.4.3.
The CPU enters system state on three occasions:
- Execution of a MON instruction is user state.
This instruction is the only way for a process
to execute a system call. CF. 3.7.1.4. Any other
attempt by a process to enter the kernel program
will be trapped as a memory protection violation.
- The CPU is interrupted by the MAP. Cf. 3.7.1.5
- The CPU interrupts its own execution. Cf. 3.7.1.5.
3.7.1.3.1 I̲n̲s̲t̲r̲u̲c̲t̲i̲o̲n̲ ̲E̲x̲e̲c̲u̲t̲i̲o̲n̲
All assigned CPU instructions are completely documented
with all effects described. Unassigned instructions
are trapped by an internal interrupt, cf. 3.7.1.5.2,
causing the executing process to be stopped.
Priviledged instructions fall into two classes:
- Normal priviledged instructions.
These must only be executed in system state.
- Highly priviledged instructions.
These must only be executed in system state at
level 15. They include all the I/O instructions
and those instructions which may change the memory
mapping.
3.7.1.4 M̲O̲N̲i̲t̲o̲r̲ ̲I̲n̲s̲t̲r̲u̲c̲t̲i̲o̲n̲
The MONitor instruction is used to execute a system
call. It can be executed in User state or System state.
The instruction has as the only operand the system
call identification.
Each system call has an associated system level ranging
from 1 to 15 and a location of the kernel program to
execute the call. This information is located in the
Monitor Table within the Kernel Program.
The function of the MON instruction is (cf. figure
3.7.1-3):
- Set CPU state to System state.
- Use the system call identification as an index
in the monitor table. Fetch location and system
level from the entry.
- Use system level as an index into the Bound Register
MAP and load the bound register associated with
the system level.
- Enter the location fetched from monitor table.
3.7.1.5 I̲n̲t̲e̲r̲r̲u̲p̲t̲s̲
An Interrupt is defined as:
- an event which is unrelated to the current
program being executed and beyond the control
of that program (external interrupts),
- an event which is related to a fault condition
caused by the program.
In both cases, the current process is preempted, and
control is transferred to the operating system kernel.
3.7.1.5.1 E̲x̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲r̲u̲p̲t̲s̲
These interrupts are initiated by MAP for one of the
following reasons:
- Interrupt signals from peripheral modules, including
real time clock.
- Time Out from a memory module or a peripheral module.
3.7.1.5.2 I̲n̲t̲e̲r̲n̲a̲l̲ ̲I̲n̲t̲e̲r̲r̲u̲p̲t̲s̲
These interrupts can be initiated by the MAP or by
the CPU itself. They are:
- Memory Access Rights violation (cf. 3.7.1.2)
- Bound Register violation.
- Execution of a priviledged instruction or a TRAP
instruction is user state.
- Execution in system state, level 1-14 of an instruction
which is priviledged at level 15.
- Stack overflow.
3.7.1.5.3 I̲n̲t̲e̲r̲r̲u̲p̲t̲ ̲H̲a̲n̲d̲l̲i̲n̲g̲ ̲
An interrupt will cause the CPU to:
- Stack the current CPU context
- Enter system state at level 15
- Enter an interrupt handling location in the kernel
program depending upon the interrupt.
Internal interrupts will cause the current process
to be stopped and a notification to be sent to the
operating system, which may then decide to abort the
process causing the interrupt.
External interrupts will cause the CPU to enter the
device handler, which is responsible for the peripheral
module requesting the interrupt.
PU RAM CPU
(1-5)
MAP
Data Channel
Peripheral Module
CU RAM Peripheral DEVICE
Processor
Figure 3.7.1-1…01…Principal Hardware Architecture
CPU
Logical M̲A̲P̲ Physical Address
Address
Space Address
Transla-
tion
1K
Logical 64K Program
Program words (read)
Space 1K
1K 1K
Logial 64K data
Data words (write) 1K
Space 1K
1K
1K
1K
Figure 3.7.1-2…01…Address Translation
255
Monitor Kernel
Table Program
Location
Level
Bound
Register
Max
Kernel
Data
Figure 3.7.1-3…01…Monitor Instruction
3.7.1.6 I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲C̲h̲e̲c̲k̲s̲
3.7.1.6.1 P̲a̲s̲s̲i̲v̲e̲ ̲C̲h̲e̲c̲k̲s̲
Redundancy checks (e.g. parity) are applied throughout
the system in order to detect any modifications of
information stored in or transmitted within the system.
This includes:
- PU RAM
- CU RAM
- Busses
- Internal registers in CPU and MAP modules.
3.7.1.6.2 A̲c̲t̲i̲v̲e̲ ̲C̲h̲e̲c̲k̲s̲
All internal information transfers are supervised by
a timeout mechanism in the MAP module, detecting any
disconnection of a module from the system.
All active modules, e.g. MAP, CPU, Peripheral Modules
include a self test program, which is entered during
start up. The module will only be accepted as operational,
if the start up test succeeds. The internal test facilities
of peripheral modules may be exercised during the online
operation.
3.7.1.7 C̲o̲n̲f̲i̲g̲u̲r̲a̲t̲i̲o̲n̲ ̲C̲o̲n̲t̲r̲o̲l̲
All peripheral modules are constructed so as to supervise
the connection status of the attached devices. Any
temporary or permanent disconnection of a device (e.g.
removal of a disk pack) will be reported. This is done
by an immediate interrupt or by returning an error
condition as a response to the next command.
A device (e.g. a communication line) can thus not be
replaced without notification of the operating system.
3.7.1.8 P̲a̲c̲k̲a̲g̲i̲n̲g̲ ̲a̲n̲d̲ ̲C̲a̲b̲l̲i̲n̲g̲
The installation of equipment and cables will be made
in accordance with the applicable criteria as defined
in AMSG 719B.
Installation details are described in a separate section
in this proposal.
The proposed equipment can be grouped in the following
2 categories.
- equipment mounted in EMI-racks
- selfstanding peripherals and terminals.
3.7.1.8.1 E̲q̲u̲i̲p̲m̲e̲n̲t̲ ̲i̲n̲ ̲E̲M̲I̲-̲r̲a̲c̲k̲s̲
The EMI-rack design, including filtering of power lines
and signal lines has been certified to comply with
AMSG 720A-requirements.
The certification is issued for racks equipped with
Processors, peripherals etc.
The same as the proposed configuration.
During the production of the racks, the manufacturing
is controlled in accordance with specially established
quality inspection criteria to ensure, that the potential
risk areas for excessive emanation are carefully handled
in manufacturing.
Specially, the tolerances around the doors are minimized,
and once the doors are adjusted at the factory, no
field adjustment is required.
3.7.1.8.2 S̲e̲l̲f̲s̲t̲a̲n̲d̲i̲n̲g̲ ̲p̲e̲r̲i̲p̲h̲e̲r̲a̲l̲s̲ ̲a̲n̲d̲ ̲t̲e̲r̲m̲i̲n̲a̲l̲s̲
The following peripherals and terminals, which are
processing NATO classified information, complies with
AMSG 720A:
a) Alphanumeric terminal
b) Colorgraphic terminal
c) Hardcopier
d) Large Group Display unit
e) Line Printer
f) Color Plotter
g) Paper Tape Unit
h) Medium Speed Printer
(for Operator position)
The Colorgraphic Monitors will be equipped with degaussing
facilities, which meet NATO regulations.
In order to minimize enamation of compromizing signals,
the serial communication lines between main racks and
peripherals/terminals use low level keying (6-0-6 volts)
and waveshaping on the electrical lines.
For the communication lines from the main racks to
the alphanumeric and graphic workstations, optical
fibre lines are employed.
3.7.2 S̲e̲c̲u̲r̲i̲t̲y̲ ̲A̲s̲s̲u̲r̲a̲n̲c̲e̲ ̲v̲i̲a̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
3.7.2.1 S̲u̲m̲m̲a̲r̲y̲
This section describes implementation details about
the following major security areas:
- Terminal Security
- Data Base Security
- Security Audit
- Security Administration
3.7.2.2 T̲e̲r̲m̲i̲n̲a̲l̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲
This section described the security mechanisms controlling
user access to the system via interactive terminals.
These mechanisms constitute the basic vehicle for the
Man Machine Interface, enforcing the required security
upon all user transactions.
3.7.2.2.1 O̲b̲j̲e̲c̲t̲i̲v̲e̲s̲
The major objectives in designing terminal security
are:
- Encapsulation of security mechanisms:
The Trusted Computer Base will enforce the security
policy upon the software modules performing data
manipulation, e.g. user transactions. Those software
modules are not part of TCB, and errors in the
modules can thus not affect security.
- Operational Security:
-- The Trusted Computer Base will enforce proper
authentication of the termial and the user
at the terminal, and require reauthentication
after security relevant events as specified
by the Security Administrator.
-- The Trusted Computer Base will continuously
inform the user of the security classification
of the data currently shown on the terminal.
The security functions for terminals are handled by
Terminal Monitoring and Control (TEMCO), which is part
of the System Status and Control Module of DAMOS Operating
System, see section 3.7.3.2.2.1.3.
3.7.2.2.2 M̲a̲n̲ ̲M̲a̲c̲h̲i̲n̲e̲ ̲I̲n̲t̲e̲r̲f̲a̲c̲e̲
The basic concepts in the Man Mahince Interface are
used to separate activities and are defined as sessions
and transactions.
A transaction is a logical unit of work, such as:
- Preparing a single message.
- Forming a data base query and displaying the results.
- Displaying a received message.
A transaction will normally consist of a series of
interactions (input from user followed by response
from system).
A session is an unbroken sequence of transactions performed
by one user at one terminal. It is bracketed by Sign
On and Sign Off by the user.
3.7.2.2.2.1 S̲e̲c̲u̲r̲i̲t̲y̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
The Security Attributes used to enforce terminal security
are:
- Security Profile:
A security profile is an aggregate of a Security
Level ranging from NATO UNCLASSIFIED to COSMIC
TOP SECRET and a set of 45 Security Categories.
Each security category represents some additional
caveat, such as ATOMAL.
- Use Group Id (UGI)
An identification of a user or a group of users.
The security profile is used to enforce Mandatory Security
while the UGI is used to enforce Discretionary Security.
For a more detailed description refer to 3.7.3.2.5.
a) Transactions and sessions have the following security
attributes associated with them:
- Security Profile
- User Group Id (UGI)
The UGI remains unchanged during the session. So
does the security profile of the session, while
the security profiles of the transactions may vary.
The security profile of a transaction within a
session must however, always be dominated by the
security profile of the session.
b) Assignment of Security Attributes:
The security attributes of a session are assigned
during Sign On:
- The security profile is the minimum of the
profile of the user, the profile of the terminal
and an optional profile entered by the user
during Sign On. Cf.3.7.2.2.4.
- The UGI is that of the user.
The security attributes of transactions are assigned
at transaction start:
- The security profile is established automatically
by the system if the transaction consists of
displaying data queued for the terminal.
- The security profile is established by a command
from the user, if the transaction can result
in any updates of data within the system.
- The UGI is that of the session.
3.7.2.2.2.2 I̲n̲i̲t̲i̲a̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲T̲e̲r̲m̲i̲n̲a̲t̲i̲o̲n̲
a) A session is initiated by a SIGN ON command from
a user, cf. 3.7.2.2.4. Upon a successful Sign On,
the security profile and UGI of the session is
established as described in 3.7.2.2.2.1 b).
b) A session is terminated by:
- SIGN OFF command from user. Cf. 3.7.2.2.5.1.
- Automatic Sign Off by system. Cf. 3.7.2.2.5.2.
VDU memory is automatically erased upon Sign
Off, cf. 3.7.2.2.8.
c) A transaction is initiated by the user entering
a command. Cf. 3.7.2.2.6.2.
The security profile is established automatically
by the system or by user entered parameters with
the command.
If when creating the new security profile, it is
dominated by the previous one, the VDU memory is
automatically erased, cf. 3.7.2.2.8. On the same
conditions the memory of the software task handling
the previous transaction is erased.
d) A transaction is terminated by:
- Normal Completion.
- Abnormal Completion:
-- The user entering a command such as SIGN
OFF, CANCEL, SUSPEND
-- Automatic Sign Off.
-- Security Violation.
Any attempt by a transaction to violate
the current mandatory or discretionary
access rights is considered a security
violation.
Initiation and termination of sessions and transactions,
including establishment of security attributes, are
managed by TEMCO. Each of these events are logged on
the Security Log, cf. 3.7.3.
3.7.2.2.2.3 S̲e̲c̲u̲r̲i̲t̲y̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲ ̲o̲f̲ ̲U̲s̲e̲r̲s̲ ̲a̲n̲d̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲s̲
Each User and each terminal have a set of associated
security attributes. They are used to establish the
security attributes of a session during Sign On.
The security attributes are assigned and maintained
by the security administrator, cf. 3.7.2.5.1.1.
a) S̲e̲c̲u̲r̲i̲t̲y̲ ̲a̲t̲t̲r̲i̲b̲u̲t̲e̲s̲ ̲o̲f̲ ̲U̲s̲e̲r̲s̲
Each user has the following security attributes:
- Security Profile:
The highest security profile of data that the
user is allowed to access. This profile will
limit the security profile of any session that
the user may initiate at any terminal.
- UGI:
The user group id of the user.
This UGI is associated with any transaction
initiated by the user.
b) S̲e̲c̲u̲r̲i̲t̲y̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲ ̲o̲f̲ ̲T̲e̲r̲m̲i̲n̲a̲l̲s̲
Each terminal has the following security attributes:
- Security Profile:
The highest security profile of data which
can be accessed from this terminal. This profile
will limit the security profile of any session
initiated at the terminal by any user.
- Access Control List:
A list of UGI's for users which are allowed
to sign on at the terminal.
3.7.2.2.3 A̲u̲t̲h̲e̲n̲t̲i̲c̲a̲t̲i̲o̲n̲
The identities of the terminal and the user are continuously
monitored as follows:
a) Terminal Authentication.
The Terminal and channel number is established
by the security manager and controlled by security
tables (Refer to 3.7.2.5.1.1).
Any disconnection of the terminal will cause an
automatic sign off.
b) User Authentication.
Users identify themselves by means of:
1) A security key
2) User Name
3) Password
During sign on, TEMCO will check the consistency of
the user and the password. The password will not be
shown on the terminal. Note also that passwords are
kept internally in encrypted from, cf. 3.7.2.5.1.1.(a).
During a session the user will be interrogated for
his password at the following occasions:
- Before execution of selected transactions, as specified
by Security Administrator.
- Before execution of any transaction, the security
profile of which is above an interrogation profile
specified by Security Administrator.
An automatic sign off will take place upon a specified
number of failed attempts to enter a correct password.
3.7.2.2.4 S̲i̲g̲n̲ ̲O̲n̲
A user initiates a session by issuing the SIGN ON command
to TEMCO in the security split, cf. 3.7.2.2.6. The
user is required to enter user name and password. The
password will not be shown on terminal. An optional
security profile may be entered too. The security key
must be in the ON position.
TEMCO checks the consistency of the entered parameters.
The user is allowed a predefined number of unsuccessful
attempts to sign on. If the threshold is reached, the
terminal will be blocked.
Sign On can not be done, if the terminal is blocked,
cf. 3.7.2.2.5.3.
3.7.2.2.5 S̲i̲g̲n̲ ̲O̲f̲f̲
A Sign off terminates the current session. The terminal
memory will be cleared upon a sign off.
3.7.2.2.5.1 S̲i̲g̲n̲ ̲O̲f̲f̲ ̲C̲o̲m̲m̲a̲n̲d̲
The user terminates a session by issuing a SIGN OFF
command to TEMCO.
3.7.2.2.5.2 A̲u̲t̲o̲m̲a̲t̲i̲c̲ ̲S̲i̲g̲n̲ ̲O̲f̲f̲
An automatic sign off of the user will be done when:
- The terminal becomes physically disconnected.
- The user fails to enter the correct password during
security interrogation, cf. 3.7.2.2.3(b).
- The terminal becomes blocked by command from Security
Administrator as described in the secutirites procedures
manual.
- Any threshold monitoring violation of the users
access rights is reached.
- The terminal is inactive for a period longer than
the one specified for the current security level.
3.7.2.2.5.3 T̲e̲r̲m̲i̲n̲a̲l̲ ̲B̲l̲o̲c̲k̲i̲n̲g̲
A terminal can be logically blocked, meaning that sign
on at the terminal is not permitted.
The terminal becomes blocked, if:
- Security violation attempts of types, identified
in security procedure manual, which shall cause
terminal blocking, such as unsuccessfull entering
of password, cf. 3.7.2.2.4.
- The security administrator issues a 'block terminal'
command for the terminal, cf. 3.7.2.5.4.
A blocked terminal can only become unblocked by a command
from security administrator.
3.7.2.2.6 S̲e̲c̲u̲r̲i̲t̲y̲ ̲S̲p̲l̲i̲t̲
The screen of a terminal is divided into two parts,
one being the s̲e̲c̲u̲r̲i̲t̲y̲ ̲s̲p̲l̲i̲t̲, the other the f̲o̲r̲m̲a̲t̲
̲s̲p̲l̲i̲t̲.
The security split is the part of the VDU used for
communication between the user and TEMCO.
No software module outside TEMCO will be allowed to
access the security split.
The security split is an implementation of the Trusted
Path facility required in B3 requirements.
The security split contains a Security Attribute line.
On Alpha Terminals it contains in addition a Security
Command/Response Line.
3.7.2.2.6.1 S̲e̲c̲u̲r̲i̲t̲y̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲ ̲L̲i̲n̲e̲
A Line of the security split where TEMCO displays the
security profile of the current transaction.
The security consists of (cf. 3.7.2.2.2.1.):
- security level
- security categories
Alpha as well as graphics displays shall have a security
attributes line.
This line shall also contain an identification of the
current transaction.
3.7.2.2.6.2 S̲e̲c̲u̲r̲i̲t̲y̲ ̲C̲o̲m̲m̲a̲n̲d̲/̲R̲e̲s̲p̲o̲n̲s̲e̲ ̲L̲i̲n̲e̲
This line of the security split shall only exist on
alpha terminals. It shall only be used for communication
between TEMCO and the user. All commands for initiation
and termination of session and transactions are entered
in the security command/response line.
Commands to application software within a transaction
are entered in the format split.
One or more function keys can be assigned to the security
commands. Depressing any of these will cause control
of the terminal to be taken over by TEMCO.
3.7.2.2.7 C̲h̲a̲n̲g̲e̲ ̲o̲f̲ ̲P̲a̲s̲s̲w̲o̲r̲d̲
The password of a user can always be changed by the
securitiy adminstrator. As an option, the password
may also be changed by the user during a session based
upon the security procedure manual direction.
This is done by a Change Password command to TEMCO.
Security Interrogatin will always be required for this
transaction. Cf. 3.7.2.2.3.b.
3.7.2.2.8 R̲e̲l̲a̲t̲i̲o̲n̲ ̲t̲o̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲M̲o̲d̲e̲l̲
As explained in previous sections, terminal security
is managed by TEMCO, which is part of Trusted Computer
Base.
At the beginning of each transaction TEMCO initiaties
an untrusted user process, operating with the security
attributes of the transaction and allows it to communicated
with the user via the format split of the terminals,
cf. 3.7.2.2.6. Within the system this user process
now acts on behalf of the user during execution of
the transaction.
The mandatory and discretionary access control rules
described in section 3.7.3.2.5 are automatically enforced
upon any data access performed by an untrusted process.
In this way TEMCO ensures that the user process and
thus the user can never access data beyond this current
access rights.
At the end of each transaction TEMCO terminates the
user process and erases its data area in main memory.
In this way it ensures that data from this transaction
can not be mixed into data for the next transaction,
which may possibly carry a lower security profile.
The terminal memory is erased upon a sign off, and
whenever the security profile of a transaction is dominated
by that of the previous transaction.
3.7.2.3 D̲a̲t̲a̲ ̲B̲a̲s̲e̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲
3.7.2.3.1 S̲u̲m̲m̲a̲r̲y̲
This section described the mechanisms used to ensure
security of the data stored by the Data Base Management
System (IDM 500 Data Base Machine).
The security of data is controlled by Data Base Management
System, DBMS and Data Base Monitoring and Control,
DMCS in cooperation. DMCS is a module in the DAMOS
Operating System, cf, 3.7.3.2.3.2.
The topics covered in this section are:
- Description of Data Base Objects
- Security Functions of Data Base Management System
- Security Functions of Data Base Monitoring and
Control.
- Additional Integrity Checks of Data Base Management
System.
- Assurance of Data Base Management System Software.
3.7.2.3.2 D̲a̲t̲a̲ ̲B̲a̲s̲e̲ ̲O̲b̲j̲e̲c̲t̲s̲
For the sake of clarity, a few basic concepts of DBMS
are explained.
Data are stored in r̲e̲l̲a̲t̲i̲o̲n̲s̲, which are similar to
files in other systems.
A relation consists of a variable number of t̲u̲p̲l̲e̲s̲,
which are similar to records. A tuple is a collection
of information about an entity.
A tuple consists of a fixed number of a̲t̲t̲r̲i̲b̲u̲t̲e̲s̲, which
are similar to fields. An attribute is an information
atom which can not be broken further down.
The o̲b̲j̲e̲c̲t̲s̲ (Cf. 3.7.3.2.5) are the tuples. Each tuple
has its own security profile attribute for mandatory
access control. Discretionary access control is done
on relations. So all tuples in a relation have the
same discretionary security attributes (Access Control
List).
A relation can easily be broken into two relations,
where some of the attributes of the original tuples
go to one relation while the remaining attributes go
to the other relation. The only penalty is a slight
overhead in access to the data. The association of
security profile to tuples (records along with attributes
fields) is an additional level of security. At times
data fields (elements) might have a classification
level but collectively have a higher classification
level.
3.7.2.3.3 S̲e̲c̲u̲r̲i̲t̲y̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲o̲f̲ ̲D̲a̲t̲a̲ ̲B̲a̲s̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲
This section descibes the mechanism implemented in
DBMS for security control. The functions of Data Base
Monitoring and Control for support of these mechanisms
are described in 3.7.2.3.4.
3.7.2.3.3.1 V̲i̲e̲w̲
In Codasyl terminology, a relation is similar to an
internal schema. The concept of a view in DBMS is similar
to an external schema.
Only the Data Base Administrator (a particular User),
will be allowed to access relations directly. All other
users and processes must access relations indirectly
via views, defined by Data Base Administrator and security
administrator if the functions are separated.
A view is a "virtual relation". It is defined by means
of real relations. A tuple of a view consists of a
defined subset of the attributes of one or more real
relations. A number of additional conditions may be
superimposed by the view, such as a specific attribute
being within a certain range.
A user process accessing a view will never be aware
of the existence of the relations constituting the
view or the existence of tuples excluded by the additional
conditions of the view.
Views are subject to discretionary access control in
the same way as relations, e.g. views will have a security
classification if associated with a view.
3.7.2.3.3.2 M̲a̲n̲d̲a̲t̲o̲r̲y̲ ̲A̲c̲c̲e̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲
Each tuple of the real relations has a security profile
attribute, consisting of security level and security
categories as defined in 3.7.3.2.5.2.
This security profile attribute or the basis for mandatory
access control. The rules are:
- Retrieve Access.
A necessary condition that a process is allowed
to retrieve any attribute from a tuple is, that
the security profile of the process dominates that
of the tuple.
- Append Access.
If an untrusted process appends a tuple to a relation,
the security profile attribute of the tuple will
be set to that of the process.
- Replace Access.
A necessary condition that an untrusted process
is allowed to replace an attribute of a tuple is
that the security profile of the process equals
that of
the tuple.
- A necessary condition that a trusted process is
allowed to replace an attribute of a tuple is that
the security profile of the process dominates that
of the tuple.
The access control rules stated above are implemented
by means of view definitions. The real relations are
always accessed via views superimposing this access
check.
3.7.2.3.3.3 D̲i̲s̲c̲r̲e̲t̲i̲o̲n̲a̲r̲y̲ ̲A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲
Discretionary Access Control applies to views, relations
and attributes within relations. For each of these
entities and each UGI (Cf. 3.7.3.2.5.2 (b)) it can
be specified, which of the functions retrieve, append
or replace that are allowed for processes with that
UGI.
3.7.2.3.4 S̲e̲c̲u̲r̲i̲t̲y̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲o̲f̲ ̲D̲a̲t̲a̲ ̲B̲a̲s̲e̲ ̲M̲o̲n̲i̲t̲o̲r̲i̲n̲g̲ ̲a̲n̲d̲
̲C̲o̲n̲t̲r̲o̲l̲
Data Base Monitoring and Control DMCS is the interface
in CR80 to the DBMS. It has the following security
functions:
- Supply Control Information with each request.
The control information to be used by DBMS for
access control is (cf. 3.7.3.2.5.2) Security Profile,
UGI and Trusted Flag of the requesting process.
- Perform Access Control on DBMS requests issued
by processes. For each UGI, a subset of the complete
set of DBMS commands is allowed.
- Create a separate audit of all requests from application
processes.
3.7.2.3.5 A̲d̲d̲i̲t̲i̲o̲n̲a̲l̲ ̲I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲C̲h̲e̲c̲k̲s̲
In order to increase the assurance that security attributes
of tuples are maintained correctly, a number of additional
integrity check can be done. They could be:
- A checksum of the complete tuple, including the
security attribute
- Minimum and maximum security profile of each relation.
Utilities can be run on request by security administrator
or at predefined intervals checking the consistence
of specified relations according to the check mechanism
described above.
3.7.2.3.6 A̲s̲s̲u̲r̲a̲n̲c̲e̲ ̲o̲f̲ ̲D̲a̲t̲a̲ ̲B̲a̲s̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
This section lists a number of properties of the DBMS
Software which are important for assessment of the
degree of confidence to the security controls performed
by DBMS.
- The IDM 500 including DBMS software is a standard
product supplied by a subcontractor.
- DBMS Software is supplied by subcontractor in object
code form.
- There are no changes or new functions in the DBMS
Software for the CCIS System.
- The only parametrization of the DBMS Software for
the CCIS System is that of the IDM 500 hardware
configuration. No parameters for resource utilization
etc., are specified in the object program.
- The DBMS software implements a set of general tools
for setup of data bases, relations, views etc.,
and for manipulation of those entities. The developers
of that software can have had no anticipation of
the contents, structure inter relationships etc.,
of the CCIS data base components. Thus no mechanisms
can have been put into the software for intentional
compromise of security.
- The IDM 500 is already used in numerous systems,
and it has shown a remarkable reliability and resistance
against tampering, so that the likelihood of unintentional
security compromise caused by flaws in DBMS software
or hardware is extremely low.
3.7.2.4 S̲e̲c̲u̲r̲i̲t̲y̲ ̲A̲u̲d̲i̲t̲
This section describes the auditing facilities in the
Trusted Computer Base. These facilities makes it possible
for a Security Administrator to audit on a terminal
security relevant events in the system, selected at
his discretion, and to analyze the security audit trail.
3.7.2.4.1 O̲b̲j̲e̲c̲t̲i̲v̲e̲s̲
The major objectives of security audit are:
- Produce in the security audit file an audit trail
of all security relevant events in the system.
- Output in real time at a security audit terminal
a subset of the complete security audit trail selected
by parameters specified by the Security Administrator.
- Offer facilities for later analysis of the security
audit trail with analysis criteria as specified
by Security Administrator.
3.7.3.2 A̲u̲d̲i̲t̲i̲n̲g̲ ̲E̲v̲e̲n̲t̲s̲
This section describes the events which shall produce
an audit record.
3.7.2.4.2.1 T̲e̲r̲m̲i̲n̲a̲l̲ ̲A̲c̲t̲i̲v̲i̲t̲i̲e̲s̲
- Sign on.
This includes successful as well as unsuccessful
attempts.
- Sign off.
Includes user initiated as well as automatic sign
off.
- Transaction start.
- Transaction Completion.
This includes normal as well as abnormal completion.
Cf. 3.7.2.2.2.2.d).
As any security violation by a user process will
automatically cause an abnormal completion of the
current trnsaction, all user attempts to violate
security will be logged this way.
- Database Access.
The opening and closing of a database file by a
user process will be logged.
- Message Access.
The opening and closing of a message by a user
process will be logged.
3.7.2.4.2.2 C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲ ̲L̲i̲n̲e̲s̲
- Connection and disconnection of line.
- Start and end of transmission of a message.
- Start and end of reception of a message.
3.7.2.4.2.3 Lo̲c̲a̲l̲ ̲D̲e̲v̲i̲c̲e̲s̲
- Mount and dismount of random access media.
- Start and end of output of message on a hardcopy
device.
- Start and end of input of message from a local
device.
3.7.2.4.3 P̲r̲o̲t̲e̲c̲t̲i̲o̲n̲ ̲o̲f̲ ̲A̲u̲d̲i̲t̲i̲n̲g̲ ̲D̲a̲t̲a̲
Auditing data will be protected by two mechanisms:
- Mandatory Protection:
A specific security category (caveat) will be reserved
for auditing data.
In particular this will prevent auditing data from
being transmitted to any device or terminal not
having acccess to this category.
- Discretionary Protection:
Only the Security Administrators user id will be
allowed access to the security log files.
The advantage of the protection mechanism is that
the privileges assigned to the Security Administrator
for performing the role of Audit Data Manager do
not require access to any other data in the system,
Cf. (B3) 3.3.3.7.4.
3.7.2.4.4 A̲u̲d̲i̲t̲ ̲T̲r̲a̲i̲l̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
The audit files will be kept in two copies, one at
the CR80 File System, the other at the IDM 500 Data
Base Machine.
There will be two kinds of tools for audit trail analysis
- An analysis utility with a predefined set of analysis
criteria. This utility uses the CR80 copy of the
audit file.
- Ad hoc analysis using the DBMS Query or Report
Writer facilities. This facility will allow for
any possible anlysis criteria. It uses the IDM
500 copy of the audit file.
3.7.2.5 S̲e̲c̲u̲r̲i̲t̲y̲ ̲A̲d̲m̲i̲n̲i̲s̲t̲r̲a̲t̲i̲o̲n̲
This section describes the data used for controlling
security, and the management of those data by the Security
Administrators.
3.7.2.5.1 S̲e̲c̲u̲r̲i̲t̲y̲ ̲D̲a̲t̲a̲
Security Data falls into three main categoties:
- Security Tables:
Tables of users, terminals, communication lines
etc., with associated security attributes and authentication
data.
- Security Parameters:
Global parameters specifying thresholds etc., such
as the automatic sign off time period for each
security level.
- Programs and Data:
The executable software modules constituting the
system.
3.7.2.5.1.1 S̲e̲c̲u̲r̲i̲t̲y̲ ̲T̲a̲b̲l̲e̲s̲
a) User Table.
Contains User Name, UGI, security profile and password
for each user known to the system. The password
is stored in one way encrypted form. The terminal
where the user is currently signed on.
b) Terminal Table.
Contains physical terminal id (answer back), security
attributes and the user names for the users which
are allowed to sign on at the terminal. The current
state of the terminal and the id of the current
user.
c) Device Table.
Contains security attributes of each local device
at the system.
d) Line Table.
Contains security attributes of each communication
line in the system.
3.7.2.5.2 P̲r̲o̲t̲e̲c̲t̲i̲o̲n̲ ̲o̲f̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲D̲a̲t̲a̲
Security Data will be protected by 3 different means:
- Mandatory Protection.
A special security category (caveat) will be reserved
for security data. In particular this prevents
security data from being transmitted to any device
or terminal not having access to this category.
- Discretionary Protection.
Only the security administrator user id's will
allow access to security data.
- Two Man Rule.
For each security table and each security parameter
it is specified at system generation time whether
the two man rule shall be enforced.This is a administration
decision to be inforced by the security administrator.
3.7.2.5.3 M̲a̲n̲i̲p̲u̲l̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲D̲a̲t̲a̲ ̲
Inspection and update of security data can be done
by certain users at certain terminals. As seen from
section 3.7.2.5.2 the conditions are:
a) The terminal must have the security data category
included into its security attributes.
b) The user must have access to the security data
category and have a UGI belonging to the set of
System Administrators.
Access to security data is performed from a terminal
by specific commands to TEMCO resulting in transactions
as described in 3.7.2.2.2.2 c). The security profile
of the transactions are automatically restricted to
the security data category.
The software modules loaded by TEMCO must be trusted
software as they access the security data. On the other
hand they do not have extended privileges such as access
to highly classified data during execution.
The two man rule is enforced by the transaction modules
whenever appropriate.
3.7.2.5.4 S̲e̲c̲u̲r̲i̲t̲y̲ ̲T̲r̲a̲n̲s̲a̲c̲t̲i̲o̲n̲s̲
Commands exist allowing the System Administrators to
do the following:
a) Maintain Security Tables:
- Inspect or update existing entries.
- Add or delete entries.
b) Inspect or update security parameters.
c) Block or unblock user terminals.
d) Initiate Audit Trail Analysis.
e) Specify parameters controlling the part of the
audit trail to be output at the audit terminal
in real time.
f) Install new versions of software modules.
The security transactions as well as the protection
philosophy for security data are described in detail
in the Security Procedures Manual.
3.7.3 S̲e̲c̲u̲r̲i̲t̲y̲ ̲A̲s̲s̲u̲r̲a̲n̲c̲e̲ ̲o̲f̲ ̲t̲h̲e̲ ̲I̲n̲t̲e̲g̲r̲a̲t̲e̲d̲ ̲S̲y̲s̲t̲e̲m̲
3.7.3.1 S̲u̲m̲m̲a̲r̲y̲
The purpose of this section is to give an overview
of the totality of security software modules in the
system and describe how these modules together with
the hardware protection facilities form a Trusted Computer
Base, which is compliant with the requirements for
a B3 system, and with the specific requirements of
the RFP security sections.
The TCB is shown to have the following main properties:
- TCB implements the Reference Monitor Concept, mediating
all access requests from application software to
system objects.
- TCB protects itself completely from any form of
tampering by users and applications software.
- TCB is highly structured. Advanced hardware and
software techniques are used for internal separation
and protection within TCB, thus enforcing the concept
of Least Privilege on the TCB modules.
- TCB is small enough to be subjected to detailed
analyses and test and supportable by security manager
(Figure 3.7.3.1-1 depicts the TCB S/W).
- Audit mechanisms are built into the system which
identify all security related event.
- TCB is extremely resistent to being penetrated
and and recovery procedures excist.
The following main topics are covered:
- Systems Architecture
Describes the structure of the TCB, its major functions
and concepts, and the mechanisms used for protection
and access control.
- Security Model
- Covert Channel Analysis
- Mapping Security
Security TCB
Figure 3.7.3.1-1
3.7.3.2 S̲y̲s̲t̲e̲m̲s̲ ̲A̲r̲c̲h̲i̲t̲e̲c̲t̲u̲r̲e̲
3.7.3.2.1 S̲u̲m̲m̲a̲r̲y̲
The purpose of this section is to describe the concepts
and structure of the software part of the Trusted Computer
Base, and the mechanisms used by TCB in controlling
the untrusted parts of the system.
The TCB consists of the following groups of modules,
listed in the order of decreasing privileges.
- DAMOS Operating System:
a) Security Kernel
b) Trusted System Processes
c) Trusted Utilities
d) Untrusted Utilities (not part of TCB)
- Trusted Applications.
These components are described in detail in the following
with particular emphasis on the privleges assigned
to each module, and the mechanisms used to protect
the modules against each other and against untrusted
software.
3.7.3.2.2 D̲A̲M̲O̲S̲ ̲O̲p̲e̲r̲a̲t̲i̲n̲g̲ ̲S̲y̲s̲t̲e̲m̲
This section describes the DAMOS Operating System with
particular emphasis on the following topics:
- Overview of modules and their functional responsibilities.
- Process Concept
- Object Concept.
Referencing of objects by processes, and access
control to objects.
- Memory Addressing.
The memory mapping hardware forms the basis of
the protection mechanisms, and is therefore described
in more detail.
3.7.3.2.2.1 D̲A̲M̲O̲S̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
The CR80 Advanced Multi Processor Operating System
DAMOS is the standard operating system for memory mapped
CR80 systems.
DAMOS is divided into operational and support software
as shown on figure 3.7.3.2.2-1
The operational software is divided into:
- Kernel
The basic process handling and security functions
- System Processes
File and Communication Handling as well as High
Level Operating System.
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
DAMOS
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
OPERATIONAL SUPPORT
SOFTWARE SOFTWARE
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲
- Kernel
- resource management - development operating
system
- directory functions - system generation software
- process management - maintenance and diagnostic
- memory management programs
- process communica-
tion
- device management
- Inter Process Data Transfer
- Application I/O Support
- Input/output system
- File Management
- Magtape Management
- Terminal Management
Database Monitoring System
Figure 3.7.3.2.2-1
DAMOS Software Overview
3.7.3.2.2.1.1 K̲e̲r̲n̲e̲l̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
a) R̲e̲s̲o̲u̲r̲c̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The goal of DAMOS Resource Management is to implement
a set of tools which enables the individual DAMOS
modules to handle resources in a coherent way.
This again, will make it possible for separate
operating systems to implement their own resource
policies without interference. Further built-in
deadlock situations will be avoided.
The resource management module governs anonymous
resources, such as control blocks. Examples of
resource types are:
- process control blocks
- segment control blocks
- synchronization elements
- PU directory entries
b) D̲i̲r̲e̲c̲t̲o̲r̲y̲ ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲
Performs the basic object management, including
creation, removal and security checking.
c) P̲r̲o̲c̲e̲s̲s̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
In the CR80 system, a clear distinction is made
between programs and their executions, called proceses.
This distinction is made logically as well as physically
by applying two different base registers: one for
program code and one for process data. This distinction
makes reentrant, unmodifiable code inevitable.
The process is the fundamental concept in CR80
terminology. The process is an execution of a program
module in a given memory area.
d) M̲e̲m̲o̲r̲y̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The addressing mechanism of the CR80 limits the
address space seen by a process at any time to
a window of 2 x 64K words. Due to the virtual memory
concept of DAMOS a process may, however, change
"position" of the window, thus leading to a practically
unlimited addressing capability.
The finest granularity of the virtual memory known
to a process is a segment. Segments can be created
and deleted and may have different sizes. A process
which has created a segment may allow others to
share the segment (restricted by security constraints)
by explicitly identifying them and stating their
access rights to the segment.
e) P̲r̲o̲c̲e̲s̲s̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲a̲t̲i̲o̲n̲
Synchronization of processes and communication
between them is supported in DAMOS by objects called
Synchronization Elements (synch elements).
The synchronization elements are used to exchange
short messages between processes. Larger amounts
of data are transferred by Inter Process Data Transfer,
yet synchronized by means of synchronization elements.
f) D̲e̲v̲i̲c̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲
The Device Manager (DVM) module is the layer of
software which provides the lowest level interface
to physical input/output devices.
The DVM consists of a number of device handlers
- one for each kind of device attached or attachable
to the CR - system and a device control block for
each physical device actually attached.
g) I̲n̲t̲e̲r̲ ̲P̲r̲o̲c̲e̲s̲s̲ ̲D̲a̲t̲a̲ ̲T̲r̲a̲n̲s̲f̲e̲r̲
This module transfers large amounts of data from
one process to another or from a process to a device.
The synchronization of the transfer is done by
means of process communication.
h) B̲a̲s̲i̲c̲ ̲A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲I̲/̲O̲ ̲S̲u̲p̲p̲o̲r̲t̲
A set of standard interface procedures through
which a user process accesses the so-called General
File Management Systems, cf. 3.7.3.2.2.1.2.
3.7.3.2.2.1.2 G̲e̲n̲e̲r̲a̲l̲ ̲F̲i̲l̲e̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲S̲y̲s̲t̲e̲m̲s̲
The Basic Application I/O Support (IOS) provides a
uniform, device independent interface for user processes
to
- disk files
- magnetic tape files
- interactive terminals
- communication lines
- line printers
The IOS is a set of standard interface procedures through
which a user communicates with a class of DAMOS service
processes known as General File Management Systems.
General File Management Systems include:
- the File Management System which implements disk
files
- the Magnetic Tape File Management System for magnetic
tape files
- the Terminal Management System for communication
lines, interactive terminals and printers.
- The Database Monitoring and Control System for
communication with the Database Management System.
3.7.3.2.2.1.3 S̲y̲s̲t̲e̲m̲ ̲S̲t̲a̲t̲u̲s̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲
The SSC package starts, allocates resources to, monitors
and controls the CCIS on-line and off-line system through
interaction between the two PUs, the peripherals, the
watchdog, and the operator.
The Terminal Monitoring and Control module (TEMCO)
controls transactions initiated by users from interactive
terminals, cf. 3.7.2.2.
The on-line modes of operation handled are:
- a dualized system consisting of one active PU and
associated peripherals and a stand-by PU
- a degraded system consisting of one active PU and
associated peripherals and an off-line PU and associated
peripherals
In the degraded system the SSC controls the off-line
operations:
- software development and test
- table generation
- maintenance and diagnostics
- offline utilities
The monitoring of the active and the standby system
includes:
- reception of error reports from other packages
- reception of hardware status from crates
- display of system status
- execution of on-line diagnostics programs
The control of the dualized and degraded system includes:
- physical connection of hardware modules
- allocation of resources to other packages e.g.
external and terminal lines
- execution of operator commands
- control of user transactions
The start-up of the dualized and degraded system includes:
- all forms of initialization
- ordered switchover to a stand-by processor and
corresponding recovery and restart actions
- recovery/restart actions during an emergency switchover
or after a total system error
3.7.3.2.2.2 P̲r̲o̲c̲e̲s̲s̲ ̲C̲o̲n̲c̲e̲p̲t̲
The active components of a CR80 system are the processes.
They are the only objects which can act as subjects,
that is act upon other objects.
Process Management is concerned with long term control
of processes (e.g. their creation and deletion from
the system).
A process may be defined as an incarnation of the data
transformations obtained by execution of a program
in a given context. A context is taken to mean a set
of CPU registers (CPU resident or saved) and the two
memory translation tables describing the logical data
space seen when the process is executing, cf. 3.7.3.2.2.4.
A process is represented by a Process Control Block
(PCB) which is identified by an object descriptor.
Each process competes with other processes for the
system resources such as CPU time, physical memory,
I/O service, etc.
During the lifetime of a process it undergoes different
process states. Figure 3.7.3.2.2.2-1 shown the process
states in conjunction with long and medium term scheduling,
and the process management functions which cause transitions
between them.
1: The process is subject to CREATE PROCESS
2: The process is subject to DELETE PROCESS
3: The process is subject to RESUME PROCESS
4: The process is subject to PASSIVATE PROCESS
Figure 3.7.3.2.2-1
Process Management
The process state ACTIVE may be further refined by
the short term scheduling (dispatching) as depicted
in fugure 3.7.3.2.2.2-2.
The events which cause transitions between the different
active states are:
1: The process is scheduled by the dispatcher
2: The process is preempted by the dispatcher
3: The process is blocked awaiting some event
4: An awaited event occurs.
Figure 3.7.3.2.2.2-2
Active Process States
P̲r̲o̲c̲e̲s̲s̲ ̲H̲i̲e̲r̲a̲r̲c̲h̲y̲
A process may create subordinate processes. These are
called child processes in relation to the creator process,
which in turn is called their parent process. See figure
3.7.3.2.2.2-3.
The purpose of having a process hierarchy is to enable
implementation of multiple operating systems each having
supreme control over the processes of its process subtree.
The hierarchy of processes in CCIS is shown in figure
3.7.3.2.2.2-4.
Figure 3.7.3.2.2.2-3
Process Hierarchy
ROOT
File Management System
Terminal Management System
Data Base Monitoring
Control
System Status and Control
TEMCO DEMCO
Terminal Device & Line
Transaction Processes ACP 127 analysis
Processes and Similar
Service Processes
Figure 3.7.3.2.2.2-4
Process Hierarchy
P̲r̲o̲c̲e̲s̲s̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
The Security Attributes of a process are:
- Security Profile
- User Group Id
- Trusted Attribute
If trusted attribute is true for a process, it
is allowed to downgrade information, by violating
the strict write access rule of the security model.
(This is discussed in detail in sections 3.7.3.2.3.4
and 3.7.3.2.5.2).
3.7.3.2.2.3 O̲b̲j̲e̲c̲t̲ ̲C̲o̲n̲c̲e̲p̲t̲
DAMOS is completely object oriented, and all references
to objects from processes takes place via indirect
references. This also applies to system processes.
3.7.3.2.2.3.1 A̲c̲c̲e̲s̲s̲ ̲t̲o̲ ̲O̲b̲j̲e̲c̲t̲s̲
Access to an object must take place in two steps:
a) The process obtains a capability to the object
by calling the appropriate object manager module
e.g. creating a memory segment by calling the Page
Manager or obtaining access to a shared synchronization
element by calling for a search in the PU Directory.
This step will create a local object descriptor,
equipped with a list of the operations on the object
which are permitted according to mandatory and
discretionary access control.
The object descriptor resides in the protected
part of the process address space at system level
15. It is built by the Directory Functions Module.
The object descriptor must be referenced indirectly
by the process using an index in the Object Descriptor
Table for the process. This is called the object
index.
b) Future accesses to the object are obtained by system
calls or system messages to the appropriate object
manager, having the object index as one of the
parameters. The object manager will invoke the
Directory Functions Module, which will do the following
checks:
- Legality of object index
- Check, if object descriptor is still valid.
One reason for invalidity could be that the
object has been removed.
- Check if the requested operation is part of
the ones permitted for the process on that
object.
- Check object level, cf. 3.7.3.2.2.3.3.
As seen from this explanation, the Reference Monitor
Concept applies to all object accesses in DAMOS, and
the mediation of references is centralized in the Directory
Functions Module.
For Data Base objects the reference mechanism is slightly
different as explained in 3.7.2.3.
3.7.3.2.2.3.2 O̲b̲j̲e̲c̲t̲ ̲T̲y̲p̲e̲s̲
DAMOS Objects are subdivided into 3 different groups,
Kernel Objects, File Objects and Data Base Objects
as explained in the following.
Within each group there is a number of different types.
Each object type is managed by a separate module, called
the Object Manager for that object type.
Kernel Objects:
Object Type Object Manager
Resource Pool Resource Management
Process Process Management
PU Process Management
CPU Process Management
CPU Pool Process Management
Memory Segment Page Manager
Synchronization Element Process Communication
Device Device Manager
File Objects:
Object Type Object Manager
Disk File File Management System
Disk Unit File Management System
Connections (terminal,
communication lines, printers)
Terminal Management
System
Data Base Objects:
Object Type Object Manager
Relation Data Base Management
System
Tuple Data Base Management
System
The description of access mediation in 3.7.3.2.2.3.1
applies directly to kernel objects. For file objects
the only difference is that the object manager is a
separate process. The object descriptor then does not
reside within the calling process but in the object
manager process.
3.7.3.2.2.3.3 L̲o̲g̲i̲c̲a̲l̲ ̲O̲b̲j̲e̲c̲t̲ ̲L̲e̲v̲e̲l̲
In addition to the protection described in previous
sections, objects are also protected by a logical level.
This enforces a logical ring protection structure upon
objects.
The reason for this additional protection is that a
process needs access to objects which are used for
various system purposes, but that those objects should
be protected from access in user mode.
Each object (incl. processes) has a logical level defined
by the object creator. In addition to the checks in
section 3.7.3.2.2.3.1(b), the following check is done
when a process issues a system call referencing an
object:
The access is only granted, if either:
- the process executes currently in system mode at
or system level equal to or above the logical level
of the object
- the process has a logical level at or above that
of the object
3.7.3.2.3 M̲e̲m̲o̲r̲y̲ ̲P̲r̲o̲t̲e̲c̲t̲i̲o̲n̲
The Memory Protection mechanisms form the basis for
protection of the Trusted Computer Base TCB from nontrusted
software. In addition to that however they are also
used to separate the modules of TCB, as described further
in section 3.7.3.2.4.2.
Main Memory is partitioned into pages. The page size
is 1024 16 bit words. The partitioning is implemented
via a memory mapping module (MAP), which performs a
translation from logical page addresses to physical
main memory page addresses. The translation is performed
by means of a set of Translation Tables (TT). A TT
defines a mapping from a set of logical page frames
into a set of main memory page frames and a set of
access rights. The MAP module contains several TTs.
Two TTs are used for each CPU, one for translation
of program addresses and one for translation of data
addresses. The TTs currently used by a CPU are identified
by means of two CPU specific Translation Table Registers
(TTR).
The domain of access rights has the elements:
. no access (full access in system state)
. read only access (full access in system state)
. full access (read and write) in all states
A translation table consists of 64 entries for mapping
of the program address space and 64 entries for mapping
of the data address space
3.7.3.2.3.1 V̲i̲e̲w̲s̲
The mapping defined by a translation table is called
a v̲i̲e̲w̲.
Whenever a CPU executes instructions, it has an associated
view. Change of view is only possible by means of a
special instructions, which can only be executed at
the highest system level in system mode.
There are two kinds of view:
- Process View, which defines the memory mapping
associated with a process
- Kernel View, which defines the memory mapping associated
with a Kernel Module. The Kernel View associated
with a manager of Kernel Objects contains all the
control and security information for the objects
managed.
3.7.3.2.2.4.2 P̲r̲o̲c̲e̲s̲s̲ ̲L̲a̲y̲o̲u̲t̲
The Layout of data in a process view is shown on figure
3.7.3.2.4.1.
The Process Parameter Segment mapped in at the highest
addresses is not accessible in user mode. It contains
all those Kernel Data for management of the process,
which are accessible in process view by the various
kernel modules.
3.7.3.2.2.4.3 S̲y̲s̲t̲e̲m̲ ̲M̲o̲d̲e̲ ̲a̲n̲d̲ ̲S̲y̲s̲t̲e̲m̲ ̲L̲e̲v̲e̲l̲s̲
A process requests a DAMOS function by executing the
MON instruction with a parameter specifying the requested
function.
The MON instruction will do the following:
- Change to System Mode.
- Set System Level according to the requested function.
- Set CPU bound register according to selected level.
- Enter the location of requested function.
There are 15 system levels. The associated bound registers
enforce a ring protection mechanism upon the Process
Parameter Segment as shown in figure 3.7.3.2.2.4.1
In System Mode it is possible to read all location
in the process address space while it is only permitted
to write at addresses below the CPU Bound Register
corresponding to current system level.
Privileged instructions are also divided into two classes:
- Normal privilege instructions which can be executed
in system mode independent of system level.
- Highly priveleged instructions which can only be
executed at level 15. They include instructions
for view change and for I/O.
The assignment of system level to kernel modules is
shown in figure 3.7.3.2.2.4.2.
3.7.3.2.3 T̲r̲u̲s̲t̲e̲d̲ ̲C̲o̲m̲p̲u̲t̲e̲r̲ ̲B̲a̲s̲e̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
This section identifies the software components of
the TCB and indicates for each component its domain
of privileges.
3.7.3.2.3.1 S̲e̲c̲u̲r̲i̲t̲y̲ ̲K̲e̲r̲n̲e̲l̲
The Security Kernel consists of the module executing
in system mode. They are listed below together with
their system level. See also figure 3.7.3.2.2.4.2,
and section 3.7.3.2.2.1 for a further description of
each module:
a) Level 15 Modules:
- Directory Functions
- Resource Manager
- Process Manager
- Page Manager
- Process Communication
- Device Manager
b) Level 12 Modules:
- Inter Process Data Transfer
o
User Data
Segment(s)
Bound 0
Process Bound 1
Parameter o
Segments o
o
Bound 14
64K
Figure 3.7.3.2.2.4.1
Process Data Layout
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
Directory Resource Process CPU Memory Process Device
15 ̲F̲u̲n̲c̲t̲i̲o̲n̲s̲ ̲ ̲M̲g̲m̲t̲.̲ ̲ ̲ ̲ ̲ ̲ ̲M̲g̲m̲t̲.̲ ̲ ̲ ̲ ̲ ̲M̲g̲m̲t̲.̲ ̲M̲g̲m̲t̲.̲ ̲ ̲ ̲C̲o̲m̲m̲u̲n̲i̲c̲ ̲ ̲M̲g̲m̲t̲.̲
̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
12 Inter Process Data Transfer
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
Basic * *
*
8 Application I/O File Terminal System Status
̲S̲u̲p̲p̲o̲r̲t̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲M̲a̲n̲a̲g̲e̲m̲e̲n̲t̲ ̲ ̲ ̲ ̲ ̲M̲a̲n̲a̲g̲m̲e̲n̲t̲ ̲ ̲ ̲ ̲a̲n̲d̲ ̲C̲o̲n̲t̲r̲o̲l̲
̲ ̲ ̲ ̲ ̲ ̲
7 Structured Application I/O Support
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
*
0 Application Processes
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
* indicates processes running in user mode
Figure 3.7.3.2.2.4.2
System Levels and Logical Levels
c) Level 8 modules:
- Basic Application I/O Support
d) Level 7 modules:
- Structured Application I/O Support
3.7.3.2.3.2 T̲r̲u̲s̲t̲e̲d̲ ̲S̲y̲s̲t̲e̲m̲ ̲P̲r̲o̲c̲e̲s̲s̲e̲s̲
These are the processes executing basic system functions.
They all execute in user mode with l̲o̲g̲i̲c̲a̲l̲ level 8.
This means that they can r̲e̲f̲e̲r̲e̲n̲c̲e̲ objects at logical
level 8 or below. Refer section 3.7.3.2.2.3.3.
The processes are:
- File Management System
- Terminal Management System
- Data Base Monitoring and Control
- System Status and Control
Except for the latter, the services are called upon
via the Basic Application I/O Support in the Security
Kernel. The processes are activated via synchronization
elements protected at level 8. Thus an untrusted application
process having logical level 0 is not even aware of
the existence of the processes and their synchronization
elements.
3.7.3.2.3.3 T̲r̲u̲s̲t̲e̲d̲ ̲U̲t̲i̲l̲i̲t̲i̲e̲s̲
This section describes the utility programs which are
used for various manipulation of security sensitive
data. They are:
- Disk Initialization.
Formats a disk unit and creates an initial file
structure on it for subsequent use by FMS. The
process does its job via FMS, and the only privilege
needed is that of writing physical sectors on disk.
- Disk Salvation
Recovers file information from garbled disk units.
Needs the privilege of accessing physical sectors,
and it must run with the highest security profile
of the data on the disk.
- Audit Analysis
Analyses the security audit trail. The privilege
needed is the security category (caveat) for audit
data, and read access to the audit trail files.
3.7.3.2.3.4 T̲r̲u̲s̲t̲e̲d̲ ̲A̲p̲p̲l̲i̲c̲a̲t̲i̲o̲n̲ ̲P̲r̲o̲c̲e̲s̲s̲e̲s̲
The modules of TCB described in section 3.7.3.2.3.1-3
is part of the standard DAMOS operating system.
The following modules are additional security sensitive
modules needed to fulfill the CCIS functional requirements.
They are:
- ACP 127 Message Analysis.
Has the function of analyzing an incoming meassage
header and derive the proper security profile.
The process must be trusted with the highest profile
which can occur for incoming messages.
- Message Body Analysis
Has the function of analyzing the text part of
a message and derive data base updates with data
of various security profile.
The process must be trusted with the highest security
profile occurring in the Data Base.
3.7.3.2.4 P̲r̲o̲t̲e̲c̲t̲i̲o̲n̲ ̲a̲n̲d̲ ̲E̲n̲c̲a̲p̲s̲u̲l̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲T̲r̲u̲s̲t̲e̲d̲ ̲C̲o̲m̲p̲u̲t̲e̲r̲ ̲ B̲a̲s̲e̲
This section summarizes the protection of TCB as follows:
- How TCB is protected from tampering by untrusted
processes.
- How TCB is internally separated into modules protected
from each other.
3.7.3.2.4.1 P̲r̲o̲t̲e̲c̲t̲i̲o̲n̲ ̲o̲f̲ ̲T̲C̲B̲ ̲a̲g̲a̲i̲n̲s̲t̲ ̲N̲o̲n̲t̲r̲u̲s̲t̲e̲d̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
a) Protection of Control Data.
The control data used by TCB for management of
the system are of various kinds and protected
in various ways as described in the following list:
- Data in process view.
These data are located in the process parameter
segment, cf. 3.7.3.2.2.4.2 It is not accessible
in user mode.
- Data in Kernel View.
These data are located in memory areas which
are only accessible by changing view. It can
only be done in system mode.
- Data in Trusted System Processes. Cf. 3.7.3.2.3.2.
These data are only accessible in process view
of the controlling process, e.g. FMS. The
view is only present in a CPU actually executing
the trusted process.
- Data on Disk.
These data are used by FMS for description
of structure, location and security attributes
of disk files. The data are located in a file
which is only accessable by FMS itself. The
ony exception is if a special privilege is
given to a Trusted Uitility like the Disk Salvation,
cf. 3.7.3.2.3.3.
b) Protection of System Objects
Certain objects are used for the purpose of cooperation
between system modules, such as communication between
Basic Application I/O Support in an application
process and the FMS.
These objects are protected by logical object level,
and are thus not accessible in user mode from untrusted
processes running at logical level 0.
3.7.3.2.4.2 I̲n̲t̲e̲r̲n̲a̲l̲ ̲S̲e̲p̲a̲r̲a̲t̲i̲o̲n̲ ̲o̲f̲ ̲T̲C̲B̲ ̲M̲o̲d̲u̲l̲e̲s̲
The data belonging to the various TCB modules are separated
and protected by various means as follows:
a) Data in Process View.
Data used by modules working in process view is
protected by system level and associated bound
registers. CF. 3.7.3.2.2.4.2
b) Data in Kernel View.
The Kernel views are separated from each other
and from process view. Change of view is done by
instructions which can only be executed at system
level 15.
c) Data in Trusted Processes
These processes execute in user mode and can thus
not access kernel data directly. They are protected
from each other by executing in disjoint process
views.
3.7.3.2.5 S̲e̲c̲u̲r̲i̲t̲y̲ ̲M̲o̲d̲e̲l̲
P̲u̲r̲p̲o̲s̲e̲
This section gives a abstract description of the basic
security concepts and access control rules which are
built into the design of the DAMOS Security Kernel.
The Security Model is a set of concepts and rules
covering the following topics:
- Subjects
- Objects
- Security Attributes of Objects.
- Access Control Rules
The security requirements and security concepts of
any particular application system built upon DAMOS
must be mapped into this model in order to enforce
automatic security control to be performed by DAMOS.
Security features which can not be mapped into this
model must be implemented by additional "security software"
outside DAMOS.
3.7.3.2.5.1 O̲b̲j̲e̲c̲t̲
The basic concept is that of an o̲b̲j̲e̲c̲t̲.
Objects are the entities which carry information.
The operations on objects which are relevent from a
security point of view are:
- Read
Means obtaining information from the object.
- Write
Means changing the information in the object.
The read and write operations have different interpretations
for different object types. There are also object types
for which either or both operations have no interpretation.
Figure 3.7.3.2.5-1 shows the object types and the interpretations
of read and write for each type. Refer also to 3.7.3.2.2.3.2.
Object Type Read Write
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
Resource Pool N/A N/A
Process N/A N/A
PU N/A N/A
CPU N/A N/A
CPU Pool N/A N/A
Memory Segment read write
Synchronizaton
Element await send
Device input output
(device dependent) (device dependent)
Disk File readbytes Appendbytes, modifybytes
Disk Unit readsectors writesectors
Connection readbytes, appendbytes,
readcontrol appendcontrol
Tuple
(Data Base
Object) retrieve append, replace
N/A: Not Applicable
Figure 3.7.3.2.5-1
Objects and their Read/Write Operations
P̲r̲o̲c̲e̲s̲s̲
A process is an object in the normal sense. It has
however, the additional property of being an a̲c̲t̲i̲v̲e̲
component of the system, that is acting as a s̲u̲b̲j̲e̲c̲t̲.
Processes are the only subjects in the CR80 system.
3.7.3.2.5.2 S̲e̲c̲u̲r̲i̲t̲y̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲s̲
Each object has a set of security attributes which
are the basis for access control.
The attributes are:
a) S̲e̲c̲u̲r̲i̲t̲y̲ ̲P̲r̲o̲f̲i̲l̲e̲.
The security profile of an object is the basis
for mandatory access control. It is an aggregate
of two constructs, s̲e̲c̲u̲r̲i̲t̲y̲ ̲l̲e̲v̲e̲l̲ and s̲e̲c̲u̲r̲i̲t̲y̲
̲c̲a̲t̲e̲g̲o̲r̲i̲e̲s̲:
Security Level is an integer ranging from 0 to
7.
It is used to encode the normal security classification.
The normal encoding is:
1: Unclassified.
2: Restricted.
3: Confidential.
4: Secret.
5: Cosmic Top Secret.
Another encoding may however, by defined for each
specific system, and the values 0, 6 and 7 may
be defined too.
Security categories is a set membership descriptor.
It indicates membership of up to 45 non hierarchical
information classes (compartments), e.g. ATOMAL.
An object can belong to any subset of these 45
classes. The CCIS notion of caveat can be mapped
to this concept, such that each caveat corresponds
to one security category.
A relation d̲o̲m̲i̲n̲a̲t̲e̲ is defined in the domain of
security profiles:
The security profile S1 dominates the security
profile S2, if the following conditions are
satisfied:
- The security level of S1 is larger than
or equal to that of S2.
- Each security category of S2 is also present
in S1.
b) U̲s̲e̲r̲ ̲G̲r̲o̲u̲p̲ ̲I̲d̲
A User Group Id, UGI, specifies a user or a group
of users.
The UGI is used for discretionary access control.
A process always represents a user, and has therefore
the UGI of that user.
Other objects have an A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲ ̲L̲i̲s̲t̲, ACL.
The ACL is a list of ACL elements. Each ACL element
consists of an UGI and a set of operations. It
expresses the access rights versus the objects
of a process with that UGI.
c) T̲r̲u̲s̲t̲e̲d̲ ̲A̲t̲t̲r̲i̲b̲u̲t̲e̲
Each process has a trusted attribute. It is a boolean
specifying, if the process is allowed to downgrade
information by violating the strict write assess
rule. Cf. 3.7.3.2.5.3.1c).
A process is called t̲r̲u̲s̲t̲e̲d̲, if its trusted attributes
is true. Otherwise it is called untrusted.
3.7.3.2.5.3 A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲
This section specifies the restrictions of the security
model on the operations which can be performed by processes.
The restrictions are divided into two classes:
- Mandatory Access Control
- Discretionary Access Control
3.7.3.2.5.3.1 M̲a̲n̲d̲a̲t̲o̲r̲y̲ ̲A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲
The Mandatory Access rules restrict operations based
upon comparison of security profiles. There are 2 distinct
rules:
a) Read Access:
A necessary condition that a processes is allowed
to read an object is that the security profile
of the process dominates that of the object.
b) Write Access:
A necessary condition that an untrusted process
is allowed to write to an object is that the security
profile of the object dominates that of the process.
3.7.3.2.5.3.2 D̲i̲s̲c̲r̲e̲t̲i̲o̲n̲a̲r̲y̲ ̲A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲
The Discretionary Access rule restricts operations
based upon Access Control List.
A necessary condition that a process may perform an
operation upon an object is that the ACL of the object
contains an ACL element for which:
1) The process has the same UGI as the ACL element
2) The operation belongs to the set of operations
of the ACL element.
3.7.3.2.5.3.3 G̲e̲n̲e̲r̲a̲l̲ ̲A̲c̲c̲e̲s̲s̲ ̲C̲o̲n̲t̲r̲o̲l̲
A necessary condition that a process is allowed to
perform an operation upon an object is that the mandatory
access control conditions as well as the discretionary
access control conditions are fulfilled.
3.7.3.2.6 E̲n̲f̲o̲r̲c̲i̲n̲g̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲o̲n̲ ̲U̲n̲t̲r̲u̲s̲t̲e̲d̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The responsibility of TCB is to enforce security requirements
upon the untrusted software components. This shall
be done is such a way that the security model is satisfied.
The security model states that access control is performed
upon processes when they access object. Thus the control
of untrusted software is done as follows:
- Untrusted software must always execute in untrusted
processes.
- Some of the untrusted processes are static and
created at system start time with static security
attributes. Examples are applications statistics
collection and manipulation.
- Other processes are tied to external users and
must change security attributes whenever the users
access rights are changed. These processes are
dynamically removed and created each time the access
rights are changed. Cf. 3 7.2.2.
3.7.3.3 C̲o̲v̲e̲r̲t̲ ̲C̲h̲a̲n̲n̲e̲l̲ ̲A̲n̲a̲l̲y̲s̲i̲s̲
This section has the following two purposes:
- Show that most of the commonly known covert channels
have been closed by the System Architecture.
- Show that the remaining covert channels have a
sufficiently low bandwidth.
The analysis addresses storage channels and timing
channels separately.
3.7.3.3.1 C̲o̲v̲e̲r̲t̲ ̲S̲t̲o̲r̲a̲g̲e̲ ̲C̲h̲a̲n̲n̲e̲l̲s̲
Most direct channels have been closed as all direct
references to data objects are subject to mandatory
access control, thus preventing any communication between
untrusted processes with different security profiles.
F̲i̲l̲e̲ ̲N̲a̲m̲e̲s̲
This also applies to directories of file names. File
directories are normal file objects, and thus subject
to normal mandatory access control.
K̲e̲r̲n̲e̲l̲ ̲O̲b̲j̲e̲c̲t̲ ̲N̲a̲m̲e̲s̲
The PU Directory managed by DAMOS Directory Function
is a potential storage channel. A process may create
an object and catalogue it in PU Directory with write
access. Processes with lower security profile may then
lookup the object and obtain the write access without
violating the mandatory access control rules. By creating
and removing the object, the higher classified process
may thus signal the lower classified process.
This channel may be closed in the following way:
- Observe that only the creator of an object is allowed
to enter the object into the PU directory or remove
it again.
- Creation of objects requires resources to be allocated
to the creating process by the operating system.
Uncontrolled object creation can thus be prevented.
- Entry of an object into the PU Directory requires
directory resources to be allocated to the calling
process by the operating system. Uncontrolled object
catalogueing can thus be prevented.
- Objects which have to appear in the PU Directory
must be created and catalogued by System Status
and Control. Untrusted processes shall have no
directory resources allocated to them.
S̲h̲a̲r̲e̲d̲ ̲R̲e̲s̲o̲u̲r̲c̲e̲s̲
Finite resources such as memory segments or disk sectors
shared between several processes can usually be used
for signalling purposes by modulating over time the
use of the resources.
The DAMOS Resource Management module enables the removal
of this type of channel by the operating system, as
resources may be separated into pools, and a pool can
be made available to only one process. The penalty
for this mechanism can be a less efficient utilization
of available resources.
3.7.3.3.2 T̲i̲m̲i̲n̲g̲ ̲C̲h̲a̲n̲n̲e̲l̲s̲
Timing channels involve a modulation of use of system
services, such that changes in response time for the
services can be observed by other processes. The most
basic service of this kind is the CPU, but the file
system and data base system are other examples.
A necessary condition for a process to be able to observe
modulation in real time is access to the real time
in sufficiently small units. Therefore, the following
rule is enforced:
An untrusted process can only read the real time
clock in units of seconds.
As real time clock can only be read via a special system
call READTIME, this rule is easily enforced.
The bandwith of any channel using real time clock as
a yard stick will then be reduced to a level below
on bit per second.
A possible timing channel not using the real time clock
would be to compare response times for file system
requests with the CPU time used by the observing process.
This could conceivably be done by polling a "request
done flag" in a loop of known execution time. It is,
however, not possible in the CR80 to observe request
completion in this way. A process can only issue a
system call awaiting completion of a specified subset
of the pending requests, and this system call will
block the process until at least one request has been
completed. A process can thus not compare its own execution
time with response time for system requests.
3.7.3.4 M̲A̲P̲P̲I̲N̲G̲ ̲S̲E̲C̲U̲R̲I̲T̲Y̲
To achieve the level of design associated with this
security write-up a security mapping procedure was
developed to map B3 requirements to capabilities required.
The task is a very comprehensive effort and will be
formalized if awarded the CCIS contract. The bidders
approach was to ensure all capabilities meet at least
the B3 requirement.
3.2.1.2.1.1 I̲n̲t̲e̲r̲a̲c̲t̲i̲v̲e̲ ̲D̲a̲t̲a̲b̲a̲s̲e̲ ̲L̲a̲n̲g̲u̲a̲g̲e̲ ̲(̲I̲D̲L̲)̲
The IDM 500 uses Interactive Database Language (IDL)
as both the language to create the structure of the
databases as well as general ad-hoc queries into the
database.
To develop a database, the Database Administrator uses
IDL to create the database and to define the relations,
the data-elements, the relational "views" of the data-elements,
the predefined accesses to the data-elements and the
other Characteristics of the database. All of these
characteristics, the Data Dictionary, is maintained
in System Relations within a database. These relations
are as follows:
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
…0f……0f…RELATION NAME DESCRIPTION…0e……0e…
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
Relation The relation is a catalog of
all objects in the database:
relations, view, files and stored
commands
Attribute Lists the attributes of each
relation and their data definitions
Indices Catalog of indices that exist
in a database, the relation
being indexed, and the attributes
included in the index
Protect Contains protection information
including type of access, for
which attributes of what object
(relation, view, stored command,
or file) for which user or group
Query Contains the text of stored
commands and views
Crossref Catalog of dependencies among
relations, views and stored
commands
Batch Temporary transaction's logging
relation for transaction management
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
…0f……0f…RELATION NAME DESCRIPTION…0e……0e…
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲ ̲
Users Mapping of user and group names
to IDM user ID
Blockalloc Catalog of disk blocks showing
relations assigned and free
space
Disk Usage Shows relation and database
allocation
Databases Catalog of database on the system
Disks Lists of disks known to the
system
Lock Used by IDM for 'read' and 'write'
lock protection
Configure Contains information about I/O
interfaces and checkpoint intervals
Dbinstat Contains information about user
currently "signed on"
A relation is a table which has rows (referred to as
tuples) and columns (referred to as attributes). Relations
can also be thought of as files, tuples as records,
and attributes as fields.
The IDM can support up to 50 unique databases. A database
can have up to 32,000 separate relations. Each relation
can hold up to 2 billion tuples (records). Each tuple
can be up to 2036 bytes long and can have up to 255
attributes. An attribute can have up to 255 bytes in
length.
Access to the "system" relations is performed by a
series of stored queries that are used to provide information
on the Static database structure as well as to dynamic
information concerning the physical size of relations
and the performance of the database.
3.2.1.2.1.2 D̲a̲t̲a̲ ̲V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲
The DBMS System has the capability of performing data
validity checks of the data prior to allowing the data
to be added to the database. An important feature of
the system is its transaction processing capability.
IDM transaction management maintains database consistency
over a set of commands. Consistency means that if two
or more transactions affect the same data, the results
will appear as if only one transaction at a time had
been operating on the data. Each command to the IDM
is a transaction unless it is one of a group of commands
between a "begin transaction" and an "end transaction"
statement. Then the entire group of commands is treated
as a single transaction. Transactions always appear
either to have run to completion or never to have started.
This level 3 consistency is automatically guaranteed
by the IDM 500.
Additionally, when making changes to information, it
is often advisable to evaluate the results of the transaction
before committing the transaction changes to the database.
The IDM 500 permits the user to do just that. Once
a "begin transaction" initiates transaction processing,
the user stores, accesses, or modifies database information
as desired. When he is satisfied with the results of
his changes, he can commit the transaction with an
"end transaction" command. Otherwise, he issues the
"abort transaction" statement which will cause the
IDM 500 to automatically back out all changes and restore
that data to its previous state just prior to the beginning
of the transaction.
4̲ ̲ ̲S̲U̲P̲P̲O̲R̲T̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
Support Software comprises:
o High-level Operating System
o System Generation Software
o Diagnostic Software
4.1 H̲I̲G̲H̲L̲E̲V̲E̲L̲ ̲O̲P̲E̲R̲A̲T̲I̲N̲G̲ ̲S̲Y̲S̲T̲E̲M̲ ̲(̲H̲I̲O̲S̲)̲
HIOS is an operating system, which provides the online
user interface for interactive and batch processing
on the CR80 computer.
The functions performed by HIOS are the following:
- define system volume and directory
- define system device(s)
- assign/deassign terminal device(s)
- create/delete terminal subdevices
- assign/deassign of disk
- reserve/release of disk
- mount/dismount of volume
- update bitmap and basic file directory
- display name of user directory
- change user directory
- listing of current status of system
- redefine current input/output
- reopen original outputfile
- maintain a user catalog
- redefine filesystem dependant I/O resources
- control online log facility
- broadcast messages between terminals
- maintain a hotnews facility
- maintain a number of batch queues
- define spool files for later output
- login/logout of terminals
- load of program
- execute task
- stop and start task
- remove task
- display current date and time
- submit batch task
HIOS is activated by the ROOT process when the system
is bootloaded. After a short initialization phase the
production phase can be entered.
In the production phase, two kinds of users can log
in on the system:
- privileged users
- non privileged users
The privilege of the user is checked at login-time
by means of the user catalog, and the privilege determines
which functions the user can execute.
All functions contained in HIOS are executed under
the constraints of the security access control mechanisms
implemented in the DAMOS kernel. This means that unauthorized
acces to any DAMOS, FMS or TMS object is impossible.
HIOS contains facilities for logging and timetagging
of all user commands and related system responses.
These facilities are used for:
- system recovery
- system performance
and load monitoring
- user assistance
4.2 S̲Y̲S̲T̲E̲M̲ ̲G̲E̲N̲E̲R̲A̲T̲I̲O̲N̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
The utility SYSGEN-EDIT generates object files - based
upon a set of directives, a system source, and command
files - for subsequent compiling and linking. A BINDER
then binds the system object together with the application
object based upon a command file from SYSGEN-EDIT.
All the external references of the object modules are
resolved in the Binder output, which is a load module
ready for execution Lood modules compiled different
languages can be executed. The BINDER produces a listing
giving memory layout, module size, etc.
The following languages are presently available:
- Cobol
- Fortran 77
- Pascal
- SWELL, the CR80 System Programming Language
- Assembler
- Ada
4.3 D̲I̲A̲G̲N̲O̲S̲T̲I̲C̲ ̲P̲R̲O̲G̲R̲A̲M̲S̲
The Maintenance and Diagnostic (M&D) package is a
collection of standard test programs which is used
to verify proper operation of the CR80 system and to
detect and isolate faults to replaceable modules.
a) O̲f̲f̲-̲l̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
The off-line M&D software package contains the following
programs:
- CPU Test Program
- CPU CACHE Test Program
- Memory Map Test Program
- RAM Test Program
- PROM Test Program
- Supra Bus I/F Test Program
- CIA Test Program
- LTU Test Program
- Disk System Test Program
- Magtape System Test Program
- Floppy Disk Test Program
- TDX-HOST I/F Test Program
- Card Reader and Line Printer Test Program
b) O̲n̲-̲L̲i̲n̲e̲ ̲D̲i̲a̲g̲n̲o̲s̲t̲i̲c̲ ̲P̲r̲o̲g̲r̲a̲m̲s̲
On-line Diagnostic programs will execute periodically
as part of the exchange survailance system. On-line
diagnostics consists of a mixture of hardware module
built-in test and reporting, and diagnostic software
routines. The following on-line diagnostic capability
exists:
- CPU-CACHE diagnostic
- TRACE diagnostic
- RAM test
- PROM test
- MAP/MIA test
- STI test
- Disk Controller/DCA test
- Tape Controller/TCA test
- LTU/LIA test
On-line diagnostics will report errors to higher level
processing to take recovery/switchover decision in
the case of failures.
5̲ ̲ ̲A̲P̲P̲L̲I̲C̲A̲T̲I̲O̲N̲ ̲S̲O̲F̲T̲W̲A̲R̲E̲
