top - download
⟦bbc1124d2⟧ Wang Wps File
Length: 70471 (0x11347)
Types: Wang Wps File
Notes: LKSAA PROPOSAL - VOL II
Names: »4231A «
Derivation
└─⟦84f7719fc⟧ Bits:30006031 8" Wang WCS floppy, CR 0385A
└─ ⟦this⟧ »4231A «
WangText
&…09…&…0e…&…01…&
&…05…&…07…%…0d…%…0f…%…06…$…0c…$…02…#…08…#…0d…# "…09…"…0e…" !…0a…!…0c…!…86…1
…02…
…02…
…02…
…02…
LKSAA - VOLUME II Issue 1.5
Part 1 SYS/84-06-15
TECHNICAL PROPOSAL Page
2.7 S̲E̲C̲U̲R̲I̲T̲Y̲
2.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̲
2.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
2.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.
2.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
2.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. 2.7.1.3.
The use of the memory protection mechanism is further
described in 2.7.3.2.2.4.
2.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 2.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. 2.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. 2.7.1.5
- The CPU interrupts its own execution. Cf. 2.7.1.5.
2.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. 2.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.
2.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
2.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.
2.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.
2.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.
2.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. 2.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.
2.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 2.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 2.7.1-2…01…Address Translation
255
Monitor Kernel
Table Program
Location
Level
Bound
Register
Max
Kernel
Data
Figure 2.7.1-3…01…Monitor Instruction
2.7.1.6 I̲n̲t̲e̲g̲r̲i̲t̲y̲ ̲C̲h̲e̲c̲k̲s̲
2.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.
2.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.
2.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.
2.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̲
2.7.2.1 S̲u̲m̲m̲a̲r̲y̲
This section describes implementation details about
the following major security areas:
- Terminal Security
- Security Audit
- Security Administration
2.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.
2.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 2.7.3.2.2.1.3.
2.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.
2.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 2.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.2.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.
2.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. 2.7.2.2.4. Upon a successful Sign On,
the security profile and UGI of the session is
established as described in 2.7.2.2.2.1 b.
b) A session is terminated by:
- SIGN OFF command from user. Cf. 2.7.2.2.5.1.
- Automatic Sign Off by system. Cf. 2.7.2.2.5.2.
VDU memory is automatically erased upon Sign
Off, cf. 2.7.2.2.8.
c) A transaction is initiated by the user entering
a command. Cf. 2.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. 2.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. 2.7.3.
2.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. 2.7.2.4.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.
2.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 2.7.2.4.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. 2.7.2.4.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.
2.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. 2.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. 2.7.2.2.4.3.
2.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.
2.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.
2.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. 2.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.
2.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. 2.7.2.2.4.
- The security administrator issues a 'block terminal'
command for the terminal, cf. 2.7.2.5.4.
A blocked terminal can only become unblocked by a command
from security administrator.
2.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.
2.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. 2.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.
2.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.
2.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. 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. 2.7.2.2.3.b.
2.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. 2.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 2.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.
2.7.2.2.9 C̲o̲m̲m̲a̲n̲d̲ ̲V̲a̲l̲i̲d̲a̲t̲i̲o̲n̲
Commands received from the Crypto Control system and
the radio control System will be security validated
again a defined list of allowed commands.
2.7.2.3 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.
2.7.2.3.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.
2.7.2.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.
2.7.2.3.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. 2.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.
- Message Access.
The opening and closing of a message by a user
process will be logged.
2.7.2.3.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.
2.7.2.3.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.
2.7.2.3.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)
2.7.2.3.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 at the CR80 File System.
There will be an analysis utility with a predefined
set of analysis criteria. This utility uses the CR80
copy of the audit file.
2.7.2.4 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.
2.7.2.4.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.
2.7.2.4.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.
2.7.2.4.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.
2.7.2.4.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 2.7.2.4.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 2.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.
2.7.2.4.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.
2.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̲
2.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.
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 2.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 2.7.3.1-1
2.7.3.2 S̲y̲s̲t̲e̲m̲s̲ ̲A̲r̲c̲h̲i̲t̲e̲c̲t̲u̲r̲e̲
2.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.
2.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.
2.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 2.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 2.7.3.2.2-1
DAMOS Software Overview
2.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. 2.7.3.2.2.1.2.
2.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 (optional for LKSAA).
- the Magnetic Tape File Management System for magnetic
tape files (optional for LKSAA)
- the Terminal Management System for communication
lines, interactive terminals and printers.
- The Database Monitoring and Control System for
communication with the Database Management System
(optional for LKSAA).
2.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 LKSAA 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. 2.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
2.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. 2.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 2.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 2.7.3.2.2-1
Process Management
The process state ACTIVE may be further refined by
the short term scheduling (dispatching) as depicted
in figure 2.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 2.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
2.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 LKSAA is shown in figure
2.7.3.2.2.2-4.
Figure 2.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 Format analysis
Processes and Similar
Service Processes
Figure 2.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 2.7.3.2.3.4
and 2.7.3.2.5.2).
2.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.
2.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. 2.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 2.7.2.3.
2.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 2.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.
2.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 2.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
2.7.3.2.2.4 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 2.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
2.7.3.2.2.4.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.
2.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
2.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.
2.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 2.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 2.7.3.2.2.4.2.
2.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.
2.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 2.7.3.2.2.4.2,
and section 2.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 2.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 2.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
2.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 2.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.
2.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.
2.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 2.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 LKSAA functional requirements.
They are:
- AA-Format and 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.
2.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.
2.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. 2.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. 2.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. 2.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.
2.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. 2.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.
2.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.
2.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 2.7.3.2.5-1 shows the object types and the interpretations
of read and write for each type. Refer also to 2.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 2.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.
2.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. The AA classifications will be
mapped into these encodings.
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 AA notion will be mapped to this concept.
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. 2.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.
2.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
2.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.
2.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.
2.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.
2.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.2.7.2.2.
2.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.
2.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.
2.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.
2.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 this option is exercised by the customer.
