top - download
⟦08b72043b⟧ Wang Wps File
Length: 37653 (0x9315)
Types: Wang Wps File
Notes: DAMOS SECURITY EVALUATION
Names: »4118A «
Derivation
└─⟦32539f54d⟧ Bits:30006181 8" Wang WCS floppy, CR 0369A
└─ ⟦this⟧ »4118A «
WangText
…1d……0d……1d……0f……1d……05……1c……0b……1c……86…1
…02…
…02…
…02…
…02…CPS/TCN/073
…02…OKH/831012…02……02…#
DAMOS
SECURITY
EVALUATION
…02……02… CAMPS
1 SCOPE ..........................................
5
2 DOD REQUIREMENTS ...............................
6
2.1 SUMMARY ....................................
6
2.2 EVALUATION APPROACH ........................
7
2.3 SUMMARY OF EVALUATION CLASSES ..............
7
2.4 EVALUATION OF DAMOS AGAINST DOD REQUIREMENTS
9
2.5 FUTURE TRENDS IN SECURITY EVALUATION .......
11
3. DAMOS SECURITY DEFICIENCIES ..................
11
3.1 SUMMARY ....................................
11
3.2 I/O ARCHITECTURE ...........................
12
3.3 PROCESS CREATION OVERHEAD ..................
13
3.4 FMS SECURITY ...............................
13
3.5 AUDIT ......................................
14
3.6 CONFIGURATION MANAGEMENT ...................
14
4 DAMOS PERFORMANCE DEFICIENCIES .................
14
4.1 PROCESS COMMUNICATION ......................
15
4.2 MEMORY MANAGEMENT ..........................
16
4.3 PROCESS CREATION ...........................
16
4.4 FMS PERFORMANCE ............................
16
5 REQUIREMENTS FOR ENHANCED DAMOS ................
17
5.1 PROCESS COMMUNICATION ......................
18
5.1.1 Purpose ................................
18
5.1.2 Queues .................................
18
5.1.3 Messages and Answers ...................
19
5.1.4 Interrupt Signals ......................
20
5.2 INPUT-OUTPUT ...............................
20
5.2.1 Purpose ................................
20
5.2.2 I/O Instructions .......................
20
5.2.3 Interrupts .............................
21
5.2.4 Basic File System ......................
21
5.3 DATA COMMUNICATIONS ........................
22
5.3.1 Purpose ................................
22
5.3.2 Security Filter ........................
22
5.4 MEMORY MANAGEMENT ..........................
24
5.4.1 Purpose ................................
24
5.4.2 MAP ....................................
24
5.4.3 Page Manager ...........................
25
5.5 PROCESS MANAGEMENT .........................
25
5.5.1 Purpose ................................
25
5.5.2 Real Time Process ......................
26
5.5.3 Recurring Process ......................
26
5.6 PROCESS CLEAN UP ...........................
27
5.6.1 Static Processes .......................
27
5.6.2 Normal Termination .....................
28
1̲ ̲ ̲S̲C̲O̲P̲E̲
The purpose of this report is to
- Describe experiences during the last couple of
years with Secure Systems.
- Discuss future trends in the area.
- Propose short term and long term HW/SW enhancements
to support secure system design with proper performance.
My sources of information and experience are
- Department of Defence:
Trusted Computer System Evaluation Criteria.
August 15, 1983.
- Participation in CAMPS design and implementation.
- Discussions with TRW security consultants.
- Participation in the CR80E discussions.
- Participation in the SACLANT proposal effort.
- Discussions with Stephen Walker, former chairman
of DOD Computer Security Technical Consortium.
The main conclusion is that a considerable development
effort is required for both hardware and software in
order to stay in the market 3-5 years from now.
The following topics will be covered in detail:
a) D̲O̲D̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
- Overview of the evaluation criteria.
- Evaluation of DAMOS against the criteria and
against other systems
- Discussion of future trends
b) D̲A̲M̲O̲S̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲ ̲D̲e̲f̲i̲c̲i̲e̲n̲c̲i̲e̲s̲
A more detailed discussion of the deficiencies
of DAMOS compared to DOD requirements.
c) D̲A̲M̲O̲S̲ ̲P̲e̲r̲f̲o̲r̲m̲a̲n̲c̲e̲ ̲D̲e̲f̲i̲c̲i̲e̲n̲c̲i̲e̲s̲
A more detailed discussion of the deficiencies
of DAMOS regarding performance.
d) D̲A̲M̲O̲S̲ ̲E̲n̲h̲a̲n̲c̲e̲m̲e̲n̲t̲s̲
A number of suggestions for short term and long
term enhancements for a secure system which can
still perform.
2̲ ̲ ̲D̲O̲D̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
2.1 S̲U̲M̲M̲A̲R̲Y̲
The DOD requirements do not present any new ideas or
concepts. They just organize security concepts and
techniques and define a scale of measurement for the
degree to which a given system implements those concepts
and techniques.
There are 7 levels ranging from level D with no security
to level A1 with maximum security. The latter is just
at the frontier of what is technically possible today.
The actual evaluation process will require that a DOD
test team analyzes system design and tests the system
for implementation flaws for a period of several months.
The current DAMOS without any enhancement will be ranked
to the next lowest level, which is C1.
With a very limited effort, DAMOS can be enhanced to
the level of B1, which is the fourth level.
With a very limited redesign but a major effort in
the area of configuration management and development
tools, DAMOS could be enhanced to the B2 level, which
is the 3rd highest level.
2.2 E̲V̲A̲L̲U̲A̲T̲I̲O̲N̲ ̲A̲P̲P̲R̲O̲A̲C̲H̲
The general idea of the DOD Requirements is as follows:
- Identify most important security properties.
- Establish for each property a scale of increasing
compliance with the ultimate goal.
- Establish a set of evaluation classes (7 at present)
having an increasing compliance with overall security
properties. Each class requires a specific minimum
evaluation for each security property.
- If a system under evaluation for a certain evaluation
class fails to meet the minimum requirement of
the class for just one property, it cannot go into
that class, no matter how compliant with other
requirements.
The kind of system they have in mind consists of at
least the following:
- DAMOS Kernel and File Systems.
- High level operating system, such as TOS or CAMPS
SSC.
- Trusted Utilities for System Generation etc.
Two interesting consequences of this approach are:
- AMOS + TOS fall into the lowest of the seven classes,
because it has no hardware protection between processes.
- DAMOS + TOS (or SSC) without enhancements fall
into the next lowest of the seven classes, as it
has no log on disk of security related events such
as:
-- Opening, closing of files or connections.
-- Log on, log off of users.
2.3 S̲U̲M̲M̲A̲R̲Y̲ ̲O̲F̲ ̲E̲V̲A̲L̲U̲A̲T̲I̲O̲N̲ ̲C̲L̲A̲S̲S̲E̲S̲
There are 4 main groups A, B, C, D where A is the highest
ranked. Group B is subdivided into B1, B2 and B3, while
group C is subdivided into C1 and C2.
Thus B3 (as required by SACLANT) is the next highest
class.
The main properties of the classes are listed below.
Only the additional properties of a class are described.
D: N̲o̲ ̲R̲e̲q̲u̲i̲r̲e̲m̲e̲n̲t̲s̲
Indicates just that the requirements of C1 were
not met.
C1: 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̲
Users and their data shall be protected against
each other. A log in procedure with password shall
be used.
C2: L̲o̲g̲ ̲O̲f̲ ̲U̲s̲e̲r̲ ̲A̲c̲t̲i̲o̲n̲s̲
The system must maintain a security log on disk
of user actions, such as log on-log off and opening-closing
of files. The log shall be available for later
analysis.
B1: L̲a̲b̲e̲l̲l̲e̲d̲ ̲S̲e̲c̲u̲r̲i̲t̲y̲
A security system with security classification
and compartments shall be supported. Security labels
shall follow all output from the system, e.g. classification
at top and bottom of all printed output.
B2: S̲t̲r̲u̲c̲t̲u̲r̲e̲d̲ ̲P̲r̲o̲t̲e̲c̲t̲i̲o̲n̲
Security software shall be completely protected
from direct or indirect modification by user programs,
and shall be highly structured internally.
A configuration management system shall be used
to automatically keep track of any changes and
to maintain and protect source, link and object
modules and to generate a system based on these
modules.
B3: M̲i̲n̲i̲m̲i̲z̲e̲ ̲T̲r̲u̲s̲t̲e̲d̲ ̲S̲o̲f̲t̲w̲a̲r̲e̲
The trusted part of the system shall be small enough
to be easily analyzed and tested. Significant engineering
effort shall be used to exclude non security relevant
software from the trusted part of the system, and
to separate and protect the modules of trusted
software from each other.
A1: V̲e̲r̲i̲f̲i̲e̲d̲ ̲D̲e̲s̲i̲g̲n̲
The trusted software shall be designed in a top
down way using a formal specification language.
Automatic verification tools shall be used to verify
that the required security properties are not compromised
during each step down in the design.
The difference between B3 and A1 is only that of the
design and verification tools.
At present Honeywell has forwarded a version of their
Mini 6 for an A1 evaluation.
2.4 E̲V̲A̲L̲U̲A̲T̲I̲O̲N̲ ̲O̲F̲ ̲D̲A̲M̲O̲S̲ ̲A̲G̲A̲I̲N̲S̲T̲ ̲D̲O̲D̲ ̲R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲
At present there are very few systems around, which
can hope for a B3 ranking, and they are typically smaller
and with less functionality than DAMOS. An example
is the Honeywell Mini 6.
As mentioned in section 2.1, the current DAMOS without
enhancements would not even reach the C2 level.
There is a large number of B3 requirements which are
not fulfilled by DAMOS (together with TOS and SSC).
Most of these can be fulfilled with very limited redesign,
even though some of them would require major effort,
such as the requirement for configuration management.
The tough requirement, which can never be met without
major redesign, is that of keeping the trusted part
of software small with a lot of internal protection
and separation between modules, and exclude from the
trusted software "all" components which are not security
relevant.
There are plenty of examples of violation of that requirement,
with most of them in the I/O area. Some of them are:
- Device Handling.
DAMOS Device Handlers are located at the most security
sensitive place in the system. They include a large
amount of protocol software for handling high level
communication protocols, such as X.25 level 3.
They are typically subject to …86…1 …02… …02… …02…
…02…
major modifications in each new project, in order to
adapt to the wide variety of equipment which shall
be connected. The internal protection between different
device handlers is minimal.
- FMS
File Directory functions are not security relevant.
Disk Cache Manager is neither security nor performance
relevant.
- IOS
90% of IOS consists of collecting user parameters
and scheduling multiple I/O requests.
- LTU/LTUX Software/Firmware
Most of this is pure protocol handling. Moreover
the software handles multilevel data, but is not
in any way structured or internally protected in
the way required for trusted software.
In addition a number of DAMOS modules are much more
complicated than would be needed. This has consequences
for security evaluation as well as for performance.
The main reasons for many of the complications are
that some of the fundamental design concepts were not
analyzed sufficiently at the early stages of the project.
This is the case for process communication, I/O and
page management as explained in later sections.
C̲o̲n̲c̲l̲u̲s̲i̲o̲n̲:̲
DAMOS is among the best existing operating systems
in terms of security. The few which are better will
typically be smaller systems with less functionality.
They are typically used for front end application etc.
With very little redesign but a major effort in configuration
management, system generation tools etc. DAMOS can
probably be evaluated to a B2 level.
An evaluation to B3 level or above will require a major
redesign effort.
2.5 F̲U̲T̲U̲R̲E̲ ̲T̲R̲E̲N̲D̲S̲ ̲I̲N̲ ̲S̲E̲C̲U̲R̲I̲T̲Y̲ ̲E̲V̲A̲L̲U̲A̲T̲I̲O̲N̲
The DOD requirements seem to be widely accepted. SACLANT
already required a B3 system !
A number of systems are already in the process of formal
evaluation with targeted evaluation level ranging from
C2 to A1.
It can be assumed that within a time frame of 2-3 years
it will be a mandatory requirement for military systems
that the operating system part has been formally evaluated.
Most systems will be required to have a ranking of
B2 or above at the time of bid submission, and the
customer may require that the vendor will enhance the
system to the A1 level during the development phase.
In order to stay in the market of secure systems, CR
must probably start up in two directions in the near
future:
- Enhance the current DAMOS and get a formal evaluation
by DOD.
- Initiate research and design activities for a next
generation of secure system, which can be evaluated
to the A1 level.
3. D̲A̲M̲O̲S̲ ̲S̲E̲C̲U̲R̲I̲T̲Y̲ ̲D̲E̲F̲I̲C̲I̲E̲N̲C̲I̲E̲S̲
3.1 S̲U̲M̲M̲A̲R̲Y̲
The security deficiencies are mainly in the following
areas:
- I/O Architecture.
-- Device handlers, including support for a number
of network protocol execute at the highest
system level.
-- LTU/TDX software/firmware must be trusted.
-- IO System and FMS/TMS include a large amount
of non security relevant functions.
- Process Creation.
The DAMOS security features cannot be effectively
utilized in transaction oriented systems like CAMPS
and CCIS.
- A security log shall be generated on disk.
- Configuration management tools are completely missing.
3.2 I̲/̲O̲ ̲A̲R̲C̲H̲I̲T̲E̲C̲T̲U̲R̲E̲
There are 3 fundamental problems with the current HW
architecture:
a) I/O instructions are privileged at highest system
level.
b) Interfaces to the various devices are not uniform.
c) Problems of SW/FW in controllers and local networks
have not been considered.
Together these have resulted in an implementation of
I/O software, which is equally poor from the security
and the performance point of view.
By introducing virtual device addresses checked by
the map module, and by letting interrupts be handled
in enabled mode, it is possible to move all the device
handling software from kernel to ordinary processes.
This would be a major step forward in terms of security.
A further redesign of Process Communication, FMS and
IOS would allow direct communication between application
process and device driver for the input output functions,
such that only the control functions for file management
etc. would have to pass through FMS. The same considerations
apply to TMS. This would improve security as well as
performance.
An independent redesign effort should be directed towards
the LTU/TDX area. This should result in a design where
the major parts of LTU, STI, TDX, LTUX etc. SW/FW can
be untrusted.
Section 5 describe the possibilities and advantages
further.
3.3 P̲R̲O̲C̲E̲S̲S̲ ̲C̲R̲E̲A̲T̲I̲O̲N̲ ̲O̲V̲E̲R̲H̲E̲A̲D̲
Systems like CAMPS and SACLANT CCIS are transaction
oriented. Users at their terminals perform transactions
displaying data from or entering data into the system,
and the security classifications of the data change
from transaction to transaction.
In order to use the DAMOS security features in transaction
oriented systems, a process must be created at initiation
of each transaction. The process must be equipped with
the security attributes needed to perform the transaction,
and with no rights beyond those needed.
The DAMOS overhead involved in creation and removal
of a process is, however, so big that this solution
is impossible in most cases. As a result the processes
executing terminal transactions are implemented as
static ones running with highest security classification.
Therefore they must be trusted.
The consequence of letting most of the software in
a system like CAMPS be trusted is of course that it
becomes practically impossible to verify the security
properties of the system. The system can therefore
not obtain a high security rating.
In section 5 the notion of "recurring process" is introduced
for a process which shall execute repeatedly with changing
security attributes. The requirement will be that the
CPU time needed to clean such a process and its associated
objects after a previous transaction and create it
again with a new security profile for a new transaction
should not exceed 50 msec. including communication
with FMS and TMS, but excluding possible load of new
program and data.
3.4 F̲M̲S̲ ̲S̲E̲C̲U̲R̲I̲T̲Y̲
Most of the functions performed by FMS are not security
relevant. Examples are:
- File Directory Functions
- Disk Cache Management
The Directory Handling could be taken out and managed
by a separate utility program. The Disk Cache Management
could presumably be removed completely, as it does
not seem to give any performance advantage as shown
below.
3.5 A̲U̲D̲I̲T̲
One of the important requirements for security is the
capability of generating log records on disk of "all
security relevant events".
DAMOS currently reports all device errors. Security
relevant events which are not reported are opening
and closing of files and connections.
The missing reports can easily be generated, so only
a small redesign is required.
The high level operating system (SSC or TOS shall write
the reports to disk in addition to writing them on
a printer.
3.6 C̲O̲N̲F̲I̲G̲U̲R̲A̲T̲I̲O̲N̲ ̲M̲A̲N̲A̲G̲E̲M̲E̲N̲T̲
The requirements for configuration management and for
documentation are very strong, even at the B2 level.
A series of design documents shall exist at various
levels of detail, and strong arguments shall be presented
to support the claim that the desired security properties
are preserved in the design transformations and in
the final implementation.
An automatic system for version control shall exist,
and it shall be possible to verify at object code level
that only those changes specified at source code level
have actually been carried out.
A configuration management system supporting these
requirements is a major effort.
4̲ ̲ ̲D̲A̲M̲O̲S̲ ̲P̲E̲R̲F̲O̲R̲M̲A̲N̲C̲E̲ ̲D̲E̲F̲I̲C̲I̲E̲N̲C̲I̲E̲S̲
It might seem that performance has nothing to do with
security. That is not true, however, as the following
two examples show:
- The early exercises in Security Kernels for PDP
11 like KSOS and PSOS have never come into practical
use because of performance limitations.
- A number of the solutions used in CAMPS are bad
ones from a security point of view, but they are
dictated by performance considerations.
The main principle, when designing functions in an
operating system, shall be:
Functions shall be layered such that high level
functions are implemented on the top of low level
ones. The main principle in defining function layers
shall be:
The lowest level shall be as simple as possible,
but it shall be of practical use for a reasonably
large class of applications. Thus it shall be possible
to build a highly efficient system using low level
tools. The higher level tools are then available
for the cases where ease of use is preferred for
efficiency.
Apparently this principle has not been used as guidelines
in DAMOS Design, as will be seen in the following.
4.1 P̲R̲O̲C̲E̲S̲S̲ ̲C̲O̲M̲M̲U̲N̲I̲C̲A̲T̲I̲O̲N̲
This is one of the most fundamental functions in an
operating system, and in DAMOS it is simply a disaster.
The following table shows the actions required by sender
and receiver in order to send a message of 500 words
and get a short reply back. The figures are msecs.
Sender Receiver
--------------------------------------------------------
lock pages 2.0
setup xferlist 0.5
send 2.5
init await 1.25
single await 3.00
xfer data 4.75
wait xfer 1.00
build OD 0.50
send 2.50
dismantle object 1.00
init await 1.25
single await 3.00
̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲ ̲
̲ ̲ ̲ ̲ ̲
9.25 14.00
Total = 23.25 msec.
Only wait xfer of 1.0 msec depends upon message length.
This is the mechanism used by IOS and FMS/TMS, so every
I/O is burdened with that communication overhead.
The reason for this state of affairs is that process
communication and transfer of data between processes
are two different functions, and that process communication
has not analyzed in advance the requirements of message-answer
mechanisms.
4.2 M̲E̲M̲O̲R̲Y̲ ̲M̲A̲N̲A̲G̲E̲M̲E̲N̲T̲
The basic page manager functions are at a too high
level. The design target has been processes needing
virtual memory with demand paging. Resident processes
having a need for resident overlays because of the
small logical address space are thus penalized by a
lot of list manipulation in the map in/map out operations.
A map in of a segment could actually be done in about
0.3 msec. but it takes actually 2.25 msecs at best,
and longer for large processes.
4.3 P̲R̲O̲C̲E̲S̲S̲ ̲C̲R̲E̲A̲T̲I̲O̲N̲
As mentioned in 3.3 it is of crucial importance to
be able to create and remove processes efficiently
in a transaction oriented environment. This cannot
be done in DAMOS.
4.4 F̲M̲S̲ ̲P̲E̲R̲F̲O̲R̲M̲A̲N̲C̲E̲
The performance of FMS is poor. This is due to two
main reasons:
- A poor process communication facility making the
transfer of control information and data between
application and FMS very inefficient.
- Internal overhead in FMS.
Only the last problem will be addressed here.
The internal overhead of FMS is about 15 msec. This
is approximately the same as the revolution time for
a CDC disk, and it is 2 times the mean access time
of a fixed head disk.
Approximately half of the overhead comes from the Disk
Cache Manager.
Theoretical analysis as well as practical measurements
show that there is virtually no advantage of using
the disk cache. It only works as a means for FMS to
keep its control structures for random files in memory,
thus avoiding extra disk accesses for access to those
files. For applications process file access, it is
only overhead and gives no advantages in exchange for
this overhead.
5 R̲E̲Q̲U̲I̲R̲E̲M̲E̲N̲T̲S̲ ̲F̲O̲R̲ ̲E̲N̲H̲A̲N̲C̲E̲D̲ ̲D̲A̲M̲O̲S̲
This section proposes a number of enhancements of DAMOS
for increased performance and security. Even though
they are considered to be enhancements, a number of
them are actually simplifications.
Some of the main criteria for selection of the enhancements
have been:
- Target Environment.
DAMOS shall not be equally suited for any type
of environment. The design center shall be that
of turn key systems with many interactive terminals
and users of varying security clearance.
Program development and similar environments have
second priority. They can be supported by building
additional features upon the basic system.
- Efficiency of Basic Tools.
The basic tools shall be suited for efficient low
level programming in the target environment. When
some application areas require higher level tools,
these must be built upon the basic ones. It shall
be possible to implement low level applications
without being penalized by functions which are
only needed for high level applications.
- Limited Hardware Changes.
The proposed enhancements can be implemented with
few or no hardware changes, even though they can
be greatly facilitated by such changes.
- Security Evaluation Growth Path.
The enhanced DAMOS can be a candidate for a formal
security evaluation at the B3 level. Based on the
experiences gained, a next generation DAMOS based
upon new hardware can then be a candidate for the
A1 level evaluation.
5.1 P̲R̲O̲C̲E̲S̲S̲ ̲C̲O̲M̲M̲U̲N̲I̲C̲A̲T̲I̲O̲N̲
5.1.1 P̲u̲r̲p̲o̲s̲e̲
The purpose of process communication is to synchronize
and exchange data between processes.
The major requirements are:
- A queued message-answer mechanism providing efficient
exchange of large amounts of data. This is the
most important facility, and shall also be the
basis for I/O from application processes.
- A queued signal facility, optionally with transfer
of a few words of data. This corresponds partly
to the current synchronization element facility.
- Semaphores for locking of shared data.
Only the semaphores need to allow await access from
more than one process.
5.1.2 Q̲u̲e̲u̲e̲s̲
A queue is similar to a f̲i̲x̲e̲d̲ set of synchronization
elements. Each of those are called subqueues. A subqueue
may be an information subqueue allowing only messsages
or signals with information or a simple subqueue allowing
only a signal without information.
Each queue has an o̲w̲n̲e̲r̲, which is the only process
allowed to await information from the queue. The security
profile of a queue may thus be identical to that of
the owner process.
When a process requests an await on the queue, it specifies
by a mask or similar mechanism a subset of the subqueues
from which it will receive information.
The purpose of the queue is to preserve the capability
of awaiting a dynamically selected subset of external
events, while removing those features which result
in heavy overhead without real advantages.
5.1.3 M̲e̲s̲s̲a̲g̲e̲s̲ ̲a̲n̲d̲ ̲A̲n̲s̲w̲e̲r̲s̲
This concept is well known from AMOS and similar systems.
It appears to be the most fundamental way of communicating
between processes, and should therefore be the design
center of process communication.
The basic requirement is that it shall be very tightly
connected to the transfer of large data blocks between
processes.
Logically a message is a carrier of read and/or write
access right for a specified data area sent to a specified
queue.
For reasons of efficiency, the data buffer may be restricted
to a contiguous buffer completely contained in a memory
segment.
A message shall be an object, and the receiving process
shall automatically get an object descriptor when the
message is received from the queue. The object descriptor
is used for subsequent access to the data of the message.
PCF shall automatically furnish the message with
- sender process id
- sender process security profile
- answer queue id
- control info for associated data.
Access to the data can be implemented by one or more
of the following mechanisms, listed in sequence of
increasing demand for HW/FW support:
- PCF makes a protected copy of the data.
- The data are accessed via block move instructions
using physical address information.
- The data are mapped into the receiving process
with bound registers protecting that part of the
segment which is not accessible.
5.1.4 I̲n̲t̲e̲r̲r̲u̲p̲t̲ ̲S̲i̲g̲n̲a̲l̲s̲
A major security enhancement will be to move the current
device handlers from the kernel to device driver processes.
Interrupts should then be directed to simple subqueues,
c.f. 5.1.2. It follows that activation of a process
when a signal is received shall be very fast, at least
for real time processes, c.f.5.5.2 The same applies
to the sending of a signal to a simple subqueue.
5.2 I̲N̲P̲U̲T̲-̲O̲U̲T̲P̲U̲T̲
5.2.1 P̲u̲r̲p̲o̲s̲e̲
The purpose of the enhancements proposed in this section
is to
- Improve security by moving device handlers from
kernel to driver processes.
- Improve access to backing storage by a simple file
system with contiguous files implemented by disk
driver. This shall remove the overhead introduced
by putting IO System and FMS in between application
process and disk handler.
5.2.2 I̲/̲O̲ ̲I̲n̲s̲t̲r̲u̲c̲t̲i̲o̲n̲s̲
I/O instructions shall be made non-privileged, at least
logically, such that device driver processes can execute
them.
This can be done in two ways:
- The most efficient way is to introduce virtual
device addresses which are mapped onto real device
addresses by MAP module.
- The virtualization may be done by software, so
that a driver executes an IO instruction via a
MON call, checking that the calling process has
access to the device.
The latter method is probably efficient enough
for the present purposes.
5.2.3 I̲n̲t̲e̲r̲r̲u̲p̲t̲s̲
Device Interrupts shall be handled by driver processes.
An interrupt shall result in a signal to a queue, c.f.
If necessary an interrupt procedure in the driver process
may be the initial handler of the interrupt. The procedure
shall be called in the context of the drive process
with timer interrupts enabled. The interrupt procedure
may be a standard one, just signalling the interrupts
to the process.
5.2.4 B̲a̲s̲i̲c̲ ̲F̲i̲l̲e̲ ̲S̲y̲s̲t̲e̲m̲
An efficient backing storage handling shall be available
for applications without any needs for a sophisticated
high level file handling.
The basic requirements are:
- The file system shall be managed by the disk driver.
- Only contiguous files need to be supported. This
may be extended if it can be done without performance
penalties or increased complexity of disk handler.
Management of file catalogues and possibly mapping
of more complex file structures onto the basic files
shall be done by a File Catalogue Process.
The application process may communicate directly with
disk driver using message-answer mechanism, c.f.5.1.
No IO system shall be required for basic file system.
The overhead of file access as seen from an application
process shall be comparable to the mean asccess time
of about 8 msecs for a fixed head disk.
5.3 D̲A̲T̲A̲ ̲C̲O̲M̲M̲U̲N̲I̲C̲A̲T̲I̲O̲N̲S̲
5.3.1 P̲u̲r̲p̲o̲s̲e̲
This area will be a weak point in security for a long
time because of the amount of software and firmware
handling network protocols at various levels, and because
new technologies are still emerging for local networks.
The main purposes are:
- Move network protocol software from kernel to driver
processes.
- Define a system structure by which security relevant
functions can be separated from protocol handling.
The structure shall as far as possible tolerate
untrusted components at all network levels.
5.3.2 S̲e̲c̲u̲r̲i̲t̲y̲ ̲F̲i̲l̲t̲e̲r̲
A security filter is a trusted subsystem which is inserted
in a data stream between untrusted componenets. It
has the capability to inspect all data in the stream
and to reject data which violate specified security
rules.
One way to separate network protocol handlers and allow
them to be untrusted is to insert security filters
at each side of the untrusted component.
Security filters can be inserted at any place in the
network architecture, and they can be implemented by
any mixture of SW, FW and HW. One obvious example of
using security filters is shown in figure 1.
The Security Filter at the terminal end is a simple
interface card, possibly integrated with an opto interface.
The two security filters shall allow for an untrusted
Network Interface Driver in the PU and/or untrusted
components of the network.
FIGURE 1
Security Filters Encapsulating Untrusted
Network Components
The filters have a simple security filter protocol
between them with the following purposes:
- Preserve data integrity across the untrusted network.
This includes correct sequencing. Possible methods
are packet sequence numbers together with CRC redundancy
checks.
- Protect against network routing errors by logical
address checks.
- If needed, protect against network tapping by end
to end encryption.
5.4 M̲E̲M̲O̲R̲Y̲ ̲M̲A̲N̲A̲G̲E̲M̲E̲N̲T̲
5.4.1 P̲u̲r̲p̲o̲s̲e̲
The memory management implemented by Page Manager and
MAP shall put special emphasis on the needs of driver
processes and interactive transaction oriented processes
in a turn key system.
It shall
- Enable efficient process switch, especially for
rather small processes.
- Enable efficient change of memory mapping by a
process for support of overlays etc.
- Enable efficient process swapping
The support for demand paging shall have second priority
and must not decrease efficiency of the other functions.
5.4.2 M̲A̲P̲
Each process has a translation table, TT, of 128 words
defining the current mapping of the logical address
space. The TT is loaded into the MAP at the following
occasions:
- When the process is selected for execution by a
CPU.
- When the TT has been changed by map in, map out
etc.
The time used for this loading of TT into MAP is about
0.25 msec.
For most processes less than 25% of the possible 128
pages are in use, and only a small part of those will
actually be used by the map until next load of TT.
The MAP should therefore only be supplied with the
physical location of TT. When a page is found absent
by MAP, it should inspect the TT in memory. If the
page is not absent there, it should load the entry
and execute the original request.
Update of TT should only result in a request to MAP
of making the corresponding entries absent. Then it
would automatically fetch the updated entries when
needed.
5.4.3 P̲a̲g̲e̲ ̲M̲a̲n̲a̲g̲e̲r̲
Most of the page manager functions use extensive list
manipulation, including search in lists. This makes
the map in and map out of segments very slow. The only
reason for all this overhead is the support for demand
paging.
Emphasis shall instead be on:
- Overlay support, including map in and map out of
segments as well as transfer of complete segments
between main memory and backing storage.
- Process swapping
This will make all list manipulation for virtual pages
superfluous.
5.5 P̲R̲O̲C̲E̲S̲S̲ ̲M̲A̲N̲A̲G̲E̲M̲E̲N̲T̲
5.5.1 P̲u̲r̲p̲o̲s̲e̲
The following two concepts shall be particularly emphasized
by process management:
- Real Time Process.
This type of process has requirements for activation
by interrupts or internal requests with a minimum
of overhead. It shall in particular be used for
driver processes.
- Recurring Process.
This type of process has requirements for efficient
cleaning and recreation with new security profile
upon a normal termination. It shall in particular
be used for execution of transactions from user
terminals with frequently changing security clearance.
5.5.2 R̲e̲a̲l̲ ̲T̲i̲m̲e̲ ̲P̲r̲o̲c̲e̲s̲s̲
A real time process is typically a driver process.
It can await interrupt signals in a simple subqueue
in parallel with requests from other processes in a
Message Subqueue, c.f.5.1.
The primary requirements are:
- Efficient activation directly by interrupts.
- CPU time accounting not necessary.
- Time slicing not necessary. Max CPU time allocation
at each activation to protect against endless loops.
5.5.3 R̲e̲c̲u̲r̲r̲i̲n̲g̲ ̲P̲r̲o̲c̲e̲s̲s̲
A recurring process is a process which could run forever
executing a series of transactions, except that the
security profile has to be changed between every two
transactions.
The purpose of introducing the concept is to allow
a change of security profile without having to go through
the tedious task of removing the process completely
and creating it again from start.
The interesting feature about a recurring process is
that it will always be started with the same context,
e.g. set of objects inherited from parent. Especially
the initial memory segments will be the same. A recurring
process will always be untrusted.
The following requirements apply:
- A new function "clean recurring" shall be used
to clean the process upon a n̲o̲r̲m̲a̲l̲ termination.
It shall check that the process has no pending
messages etc. The efficiency requirement only applies
if all those checks are passed. So normal clean
up after a failed process shall be possible but
need not be efficient.
The clean recurring function must not remove the
basic objects of the process.
- A new function "resume recurring" shall be used
to resume a recurring process with a new security
profile. This profile shall automatically be set
on the basic objects owned by the process.
5.6 P̲R̲O̲C̲E̲S̲S̲ ̲C̲L̲E̲A̲N̲ ̲U̲P̲
A large amount of the overhead of DAMOS modules arise
from the requirement of always being able to remove
a process upon command from parent.
Removal can be requested when the process has failed
or by other reasons, e.g. user regrets a transaction
just initiated. This section specifies some relaxations
to this requirement, which may be used to decrease
the associated overhead.
5.6.1 S̲t̲a̲t̲i̲c̲ ̲P̲r̲o̲c̲e̲s̲s̲e̲s̲
A number of processes in any system will be static
in the sense that once created they will never be removed
again. Typical examples are FMS, TMS and ROOT.
All actions by DAMOS modules, which are done in order
to facilitate removal of a process can be bypassed
for static processes.
5.6.2 N̲o̲r̲m̲a̲l̲ ̲T̲e̲r̲m̲i̲n̲a̲t̲i̲o̲n̲
A process has terminated normally, if it has no pending
messages, I/O activities etc.
The DAMOS modules shall facilitate fast checks of whether
a process has terminated normally. Clean up of a normally
terminated process will mostly consist of these controls.
If a process has not terminated normally, it shall
still be possible to remove the process, but it need
not be particularly efficient, as removal of failed
processes is considered a rare event in the target
environments.
