MULTICS DESIGN DOCUMENT MDD-002
To: MDD Distribution
From: R. Michael Tague
Date: August 1, 1985
Subject: Multics Security Model - Bell and LaPadula
Abstract:
The Multics system enforces a security policy that is an
implementation of the security model described by Bell and La
Padula. This Multics Design Document (MDD) presents the
relationship between the actual implementation in Multics and the
model.
Revisions:
REVISION DATE AUTHOR
initial 85-06-01 Benson I. Margulies
01 85-08-01 R. Michael Tague
_________________________________________________________________
Multics Design Documents are the official design descriptions of
the Multics Trusted Computing Base. They are internal documents,
which may be released outside of Multics System Development only
with the approval of the Director.
- i -
MDD-002 Multics Security Model
CONTENTS
Page
Introduction . . . . . . . . . . . . . 1
Multics Objects . . . . . . . . . . . 1
Segments . . . . . . . . . . . . . 1
The ROOT Directory . . . . . . . . 2
Directories . . . . . . . . . . . . 2
Message Segments . . . . . . . . . 2
Messages . . . . . . . . . . . . . 3
Non-system I/O Devices, Disk and
Tape Volumes . . . . . . . . . . . 3
Communication Channels . . . . . . 4
System Disk Volumes (Logical
Volumes) . . . . . . . . . . . . . 4
Processes (Interprocess
Communication) . . . . . . . . . . 5
Multics Subjects . . . . . . . . . . . 5
Processes . . . . . . . . . . . . . 5
Multics Access Control - Its
Relationship with the Model . . . . . 6
Discretionary Access - Access
Control List Matching . . . . . . 7
Mandatory Access Control - Security
Label Comparison . . . . . . . . . 8
Object Access Modes - Their
Correspondence to the Model . . . . . 9
Segment Access Modes . . . . . . . 9
Directory access modes: . . . . . . 10
Message Segment extended access
modes: . . . . . . . . . . . . . . 12
RCP access modes: . . . . . . . . . 14
Logical Volume access modes: . . . 15
Communication Channel access modes 15
Process access modes . . . . . . . 16
Directory Visibility and the
Compatibility Axiom . . . . . . . . . 16
ii
Multics Security Model MDD-002
_I_N_T_R_O_D_U_C_T_I_O_N
Bell and La Padula's "Unified Exposition"(1) describes the Bell
and La Padula formal model of computer system security. Section
III of the report described the correspondence between the model
and the Multics system of the time as they understood it. This
MDD describes the correspondence between the Bell and La Padula
model and Multics as it exists today.
We describe the Multics Objects, e.g., segments, directories, and
message segments, the Multics Subjects: the process, the access
modes that Multics defines for these objects, and we describe how
each Multics access mode corresponds to a Bell and La Padula
access mode. We show how the four system state variables of the
model: current access set, access permission matrix, level
function, and hierarchy are represented in Multics structures.
We further show how access to each object respects the five
axioms of the model: Compatibility, Tranquility, Activation,
Simple Security, and the *-property.
Throughout this report the Bell and La Padula model will be
referred to as the B&L model or simply the model.
_M_U_L_T_I_C_S _O_B_J_E_C_T_S
This section lists all the Trusted Computing Base protected
(TCB) objects, identifies the software that controls access to
the object (resource), describes where their discretionary (ACL)
and mandatory (label) access control attributes are stored,
describes how the security label of the object is set and to what
levels the security label may be set so as to maintain the
compatibility of the hierarchy (H) in the sense of the
compatibility axiom of the model, describes the creation and
destruction or activation and deactivation of objects (Activation
axiom).
Once set, the security label cannot be changed except by
privilege or by returning the object to the system (unassignment
for devices and communications channels, release and clearing for
volumes, deletion for all other objects). This insures the
tranquility of the hierarchy (tranquility axiom of model).
_________________________________________________________________
(1) Bell, D. E. and La Padula, L. J. , Secure Computer System:
Unified Exposition and Multics Interpretation.
ESD-TR-75-306, Mitre Technical Report MTR-2997 Rev. 1, March
1976.
1
MDD-002 Multics Security Model
_S_e_g_m_e_n_t_s
Segments are containers for information. Segments can also
be used as access control objects by associating a specific
segment (and its ACL) with another object. Segments are managed
by the "file system" in ring zero. The ACL is stored in the
containing directory, the security label is stored in both the
containing directory and Volume Table Of Contents Entry (VTOCE).
The security level is set to the level of the containing
directory, which must be equal to that of the active process
creating the segment (compatibility). The security level must be
within the range permissible for the logical volume on which the
segment resides (see below).
_T_h_e _R_O_O_T _D_i_r_e_c_t_o_r_y
The ROOT directory is a container for segments and other
objects just as other directories are, except that there is only
one ROOT directory and it has no parent. All other directories
in the system have the ROOT as the highest directory in their
parent chain of directories. The ROOT directory is managed like
other directories by the "file system" in ring zero. Its ACL is
implicit and is equivalent to status (s) permission to everyone
and status-modify-append (sma) permission to the Initializer.
The security label of the ROOT is also implicit and is system
low. Compatibility is trivial since the ROOT's security level is
dominated by all other security levels and the ROOT is the root
of the hierarchy H.
_D_i_r_e_c_t_o_r_i_e_s
Directories are containers for segments and other objects:
the building blocks of the hierarchy H. They are managed by the
"file system" in ring zero. The ACL is stored in the containing
directory, the security label is stored in both the containing
directory and VTOCE. Unless specified otherwise, the security
level is set to that of the containing directory, which must be
equal to that of the process doing the creation; however, the
creating process can specify any higher (dominating) security
level up to the maximum permitted for the user (compatibility).
_M_e_s_s_a_g_e _S_e_g_m_e_n_t_s
Message segments are containers for messages. There are
three different types of message segments: queue message
segments, used primarily as queues for requests to a server
process; mailbox message segments, used for mail and interactive
messages between users; and user-message message segments, used
for communication between the user processes and the Initializer
2
Multics Security Model MDD-002
process. The different types of message segments all implement
the same access modes (or a subset for some types of message
segments). Message segments are managed by segment control and
directory control in ring zero. The message segment software is
in ring one. All user access to message segments is mediated by
the ring one TCB. The ACL of a message segment is stored in the
containing directory, and the security label in the directory and
VTOCE. The security level is set to the maximum permitted for
the user creating the message segment, and the message segment is
allowed to contain messages of any level between that of the
containing directory and the message segment itself
(compatibility).
_M_e_s_s_a_g_e_s
Messages are the individual entries in a message segment (or
mailbox). They are managed by the message segment software in
ring one. They have no explicit ACL's; rather, discretionary
control depends only on the author of the message and the ACL on
the containing message segment. Each message has an individual
security label stored in the message header, and a single message
segment may contain messages with many different labels. The
security level is set by default to that of the sending process,
but can be increased (upgraded) either explicitly by the sending
process, or automatically if a higher level process receives the
corresponding wakeup at the time the message is sent. The
security level of a message can be no lower than that of
directory containing the message segment and no higher that the
maximun level set when the process is created, hence the
compatibility axiom is maintained.
_N_o_n_-_s_y_s_t_e_m _I_/_O _D_e_v_i_c_e_s_, _D_i_s_k _a_n_d _T_a_p_e _V_o_l_u_m_e_s
These objects are RCP-controlled (Resource Control Package)
I/O devices and volumes with no internal structure known to the
TCB. They are managed in ring one by RCP. They are recorded in
the RCP registries, which are segments managed by RCP in ring one
and inaccessible outside of RCP. By default, the ACL permits
access only to the original owner of the object. This can be
changed by recording the pathname of an owner-specified segment
in the registry; the ACL of that segment is used as the ACL for
the object.
The security label, actually a range, for these objects is
stored in the registry entry. Compatibility is maintained by
restricting the use of these objects to processes whose security
level falls within the range. The object range must fall within
the range allowed for the object type as defined in the Resource
Type Definition Table, a system table writable only by the
Initializer. When an RCP object (resource) is acquired by a user
3
MDD-002 Multics Security Model
it receives a security label with equal upper and lower limits,
both set to the current level of the acquiring process. For
devices (which have no memory of previous activation), this
assignment is temporary: when the user releases the device,
another user at a different level can acquire it. For volumes,
the assignment is permanent: once the volume is written, it
retains the label it received until it is explicitly cleared by a
security administrator. Thus the transition between active and
inactive is controlled.
_C_o_m_m_u_n_i_c_a_t_i_o_n _C_h_a_n_n_e_l_s
These resources are recorded in the Channel Definition Table
(CDT), a system table writable only by the Initializer.SysDaemon
process. All management of channels to other processes is
performed by the Initializer. The ACL for a channel is kept on a
segment of the channel's name in a system directory (>sc1>rcp).
The security label, actually a range, is stored in the CDT.
As for RCP devices, the range restricts use of the channel to
processes whose security level falls within the range. When a
channel is assigned to a process, the current security level for
the channel is temporarily set to the security level of the
requesting process. Unassigned channels have no implications on
the security model, they are inactive. The compatibility
property is maintained by the trivial nature of the communication
channel hierarchy - CDT, channel.
_S_y_s_t_e_m _D_i_s_k _V_o_l_u_m_e_s _(_L_o_g_i_c_a_l _V_o_l_u_m_e_s_)
Logical volumes are groups of disks usable by the "file
system" (page control, segment control, directory control, etc.).
They contain individually labeled segments and directories (as
opposed to RCP-controlled disks, which have no internal structure
known to the TCB). Logical volume registration is managed in
ring one by the logical volume and master directory control
software. The ACL for a logical volume is kept on a segment
whose location is stored in the registration segment. The
security label, actually a range, of a logical volume is stored
in its registration segment, which is kept in a system directory
(>lv) and also in the volume label of each disk in the logical
volume. The range restricts the security levels of the segments
that are created on that volume. The minimum and maximum values
in the range are specified by the system administrator when the
volume is initially defined to the system. Compatibility is
trivial - registration, volume. Once a volume is created, it
remains active, hence inactive volumes are not a concern.
4
Multics Security Model MDD-002
_P_r_o_c_e_s_s_e_s _(_I_n_t_e_r_p_r_o_c_e_s_s _C_o_m_m_u_n_i_c_a_t_i_o_n_)
The only operation a process may perform with respect to
another process is communication. Interprocess communication
(IPC) is mediated in ring zero by traffic control (the process
scheduler). Process creation is performed by the Initializer
process. Processes have no explicit ACL's; however, for a
process to be communicated with it must have first published one
of its IPC channel names (a number) in some predetermined
location. This provides discretionary control, since the channel
name will be unknown unless published and the names are generated
in such a way as to be a practical impossibility to calculate.
The security label for a process is stored in the Active Process
Table Entry (APTE) for the process, as well as in various places
in per-process storage. The label is derived at process creation
time from the security level ranges stored in the administrative
tables defining users (PNT), projects (SAT, PDT), and
communications channels (CDT). The security level of the object
process must dominate that of the sending process. There are no
compatibility implications, and processes are never inactive in
the Activity axiom sense.
_M_U_L_T_I_C_S _S_U_B_J_E_C_T_S
There is only one kind of subject in the Multics system: the
Multics Process.
_P_r_o_c_e_s_s_e_s
The Multics process is the agent of change in the Multics
system state. A Process may change the current access set, the
hierarchy, and access permissions. Processes may not change the
security level of objects other than to make them active or
inactive. All changes that a process may make to the system
state are constrained to conform to the axioms of compatibility,
tranquility, simple security, and *-property and to the axiom of
discretionary security. With regard to the activity axiom,
objects except for channels and RCP controlled devices cease to
exist when made inactive, channels and RCP controlled devices are
handled by the controlling subsystems such that this axiom is not
violated.
Process creation is performed by the Initializer process.
The security label for a process is stored in the Active Process
Table Entry (APTE) for the process, as well as in various places
in per-process storage. The label is derived at process creation
time from the security level ranges stored in the administrative
tables defining users (PNT), projects (SAT, PDT), and
communications channels (CDT). A process has a user ID stored in
the APTE which is used to identify the process in discretionary
5
MDD-002 Multics Security Model
access control decisions. This user ID taken with the Access
Control List (ACL) of an object and applying the matching rules
described below allow the system to calculate the access
permission the subject process has to the object, i.e., the
equivalent of looking up that access attribute for a given
subject and object in the Access Matrix M described in the Model.
_M_U_L_T_I_C_S _A_C_C_E_S_S _C_O_N_T_R_O_L _- _I_T_S _R_E_L_A_T_I_O_N_S_H_I_P _W_I_T_H _T_H_E _M_O_D_E_L
The next section describes the access modes a subject may
have with respect to the various object types and the
relationship these access modes have with the access modes of the
model. A subject's "effective access" to an object is determined
by the combination of its Discretionary Access Control (DAC)
access to an object and Mandatory Access Control (MAC) access.
It represents the set of operations a subject may perform on an
object.
The system state variable M, the access matrix, of the model
corresponds to a distributed set of software structures
throughout the Multics TCB. For most objects the information of
the access matrix corresponds to the information represented in
ACL's, Access Control Lists, stored in the containing
directories. Objects that do not exist directly in the file
system such as RCP controlled devices and logical volumes, have
Access Control Segments (ACS's) associated with them which are
ordinary segments created in the file system whose only purpose
is to possess an ACL that a TCB subsystem such as RCP may match
with a subject. The subject's access to the ACS is used to infer
that subject's access to the associated non-file system object.
These ACL's taken with their rules of interpretation elaborated
below specifically correspond to entire columns of M, that is,
the complete list of access modes that all subjects have to a
single object. For object processes, the access matrix columns
are implicit and access exists for sending IPC wakeups to a
process for all subjects that have been previously informed by
the object process of a valid IPC channel. For messages, the
access matrix column can be computed from the ACL associated with
the message segment taken together with the author subject stored
in the message itself.
All references to objects are mediated through a combination
of trusted software and hardware. The system state variable b,
the current access set, of the model corresponds to a distributed
set of temporary, mostly per process, software structures. For
some objects such as messages in message segments, elements of b
are not stored but are calculated upon each reference to the
object. For segments, the first reference to the segment is
mediated by software which computes the subject's effective
access to the segment and builds a Segment Descriptor Word (SDW)
which is used by hardware to enforce access on subsequent
6
Multics Security Model MDD-002
references to the segment. This effective access is derived from
the ACL in combination with the mandatory access relationship
determined by the subject's current security level (SL(Si) or
fc(Si) as used in the model) compared with the object's security
level (fo(Oj)). Software invalidates these SDW's forcing them to
be recalculated when a change in the current access set (ACL on
the segment) might make the current access granted by the SDW
inaccurate. These SDW's are stored in per process TCB data bases
in the process directories called the Known Segment Tables,
KST's. For directories, message segments, and messages, access
is calculated upon each reference by the associated TCB software
subsystem. For objects that have Access Control Segments
associated with them, access is calculated based on the ACS
segment and then stored in TCB data bases associated with the
subsystem controlling access and checked upon each reference.
Access of subjects to object processes is mediated upon each
reference, each IPC wakeup, by TCB software. All references to
objects are initiated by processes through calls to the TCB via
the TCB interface (subroutine interface) documented in the
Descriptive Top-Level Specification (DTLS) or to segment objects
through machine instruction memory references.
_D_i_s_c_r_e_t_i_o_n_a_r_y _A_c_c_e_s_s _- _A_c_c_e_s_s _C_o_n_t_r_o_l _L_i_s_t _M_a_t_c_h_i_n_g
Discretionary access for most objects is determined from the
Access Control List (ACL) associated with the object, and the set
of modes in the ACL term matching the subject name. An ACL term
may specify any combination of access modes for an object.
The subject name is the three component user ID associated
with each Multics subject - process. The first component of the
user ID is the account name, this often corresponds to a given
person's name. The second component is the project name, a user
is always registered on a least one project. The third component
is a process tag which by convention is used to identify
different kinds of processes; for example, an interactive user
will have a project tag of "a", while an absentee (batch) user
will have a tag of "m". A typical user ID would look like:
Tague.Multics.a.
An ACL for an object is a list of user ID's that may access
the object and which Multics access modes, read or write for
example, that that subject has to the object. The Multics system
implements certain ACL related conventions that make the
maintenance of a large computer system with many objects and
users feasible.
Four conventions are imposed:
1) No access term can appear more than once in any ACL.
7
MDD-002 Multics Security Model
2) There are eight groups of access terms which are arranged in
an ACL in the following order:
(1) no asterisk component
(2) asterisk third component only
(3) asterisk second component only
(4) asterisk second and third component only
(5) asterisk first component only
(6) asterisk first and third component only
(7) asterisk first and second component only
(8) all asterisk components
3) The entry that matches a given subject is the first access
term on the ordered ACL that matches the subject user ID.
Where matching is component by component and an asterisk ACL
term component will match any value of the corresponding
user ID component.
4) If no ACL term matches a given subject user ID, that subject
has no access or "null" ("n") access to the object.
_M_a_n_d_a_t_o_r_y _A_c_c_e_s_s _C_o_n_t_r_o_l _- _S_e_c_u_r_i_t_y _L_a_b_e_l _C_o_m_p_a_r_i_s_o_n
Multics supports eight hierarchically ordered sensitivity
levels and eighteen categories which together form a partially
ordered set of security levels under a dominate function. The
security level A is said to dominate security level B (SL(A) >=
SL(B)) if the hierarchical classification of A is greater than or
equal to that of B and the non-hierarchical categories of A
include all those of B as a subset. Security level A is said to
equal that of security level B (SL(A) = SL(B)) if level A
dominates level B and level B dominates level A (SL(A) = SL(B) if
and only if SL(A) >= SL(B) and SL(B) >= SL(A)). Security level A
is said to be isolated from security level B if neither level A
dominates level B nor level B dominates level A.
A subject's maximum security level is the minimum of:
1) the maximum user security level from the Person Name Table
(PNT) which contains a maximum and default security level
for each user,
2) the maximum project security level from the System
Administrator Table (SAT) which contains the maximum
security level for each project (users must login to some
project),
3) the maximum user security level for the project from the
Project Definition Table (PDT) which can impose a maximum
security level for a user on a particular project, and
4) the maximum communication channel security level from the
Channel Definition Table (CDT).
8
Multics Security Model MDD-002
The current subject security level is equal to the security level
specified upon login, or if not given explicitly, the default
security level specified in the PNT. The user is not allowed to
login if the current subject's security level would be greater
than that allowed by the subject's maximum security level (nor is
the user allowed to login if the current subject's security level
would be lower than the maximum of the minimum levels specified
for this user in the SAT, PDT, PNT, and CDT).
Once a user's access to login at a specified authorization,
security level, has been validated, a process is created for the
user and the security level of the subject process is stored in a
TCB data base known as the Active Process Table (APT) as well as
the per process data base known as the Process Data Segment
(PDS). This security level corresponds to the subject's current
security level or fc(Si) in the model.
The system state variable f, the level function, made up of
the three components: fs, maximum subject security level, fo -
object security level, and fc - current subject security level is
distributed among several TCB data bases in the following way:
The maximum subject security level and the current subject
security level of a given subject, process, is stored in that
process's process directory in the Process Data Segment. For
objects whose discretionary access is controlled by ACS segments,
their security level is stored in TCB data bases such as RCP
registries. For other objects, the security level is stored in
the same structure as that object's discretionary access
information, e.g., a segment's security level is stored with its
ACL in its parent directory. This state information is used with
discretionary access information, the access matrix, to compute
the effective access that is checked and enforced throughout the
Multics TCB as described above.
_O_B_J_E_C_T _A_C_C_E_S_S _M_O_D_E_S _- _T_H_E_I_R _C_O_R_R_E_S_P_O_N_D_E_N_C_E _T_O _T_H_E _M_O_D_E_L
The following subsections describe the access modes for each
type of Multics object. For each Multics access mode, a
correspondence to the access modes of the model is made. It is
through Multics' enforcement of its access modes with their
demonstrated correspondence to the access modes of the model that
Multics enforces the Simple Security axiom and the *-property
axiom.
Each section begins with a statement of mandatory access
rules that apply to all objects of this type.
9
MDD-002 Multics Security Model
_S_e_g_m_e_n_t _A_c_c_e_s_s _M_o_d_e_s
For segments, the mandatory access compatibility rule
implies that SL(o) for the segment is always equal to SL(o) for
the containing directory.
read A process granted read access can execute
(r) instructions that cause data to be fetched (read)
from the segment.
This read access maps directly to read access in the
B&L model. A subject is granted read access if the
matching ACL entry specifies _r mode and if the
subject's security level dominates the segment's
security level. SL(s) >= SL(o).
write A process granted write access can execute
(w) instructions that cause data in the segment to be
modified.
This write access maps into read and write access in
the B&L model. A subject is granted read and write
access if the matching ACL entry specifies _w mode
and if the subject's security level is equal to the
segment's security level. SL(s) = SL(o).
execute A process granted execute access can transfer to
(e) this segment and cause portions of the segment to be
interpreted and executed as instructions.
This execute access maps into execute access in the
B&L model, though it is necessary to have Multics _r
access to execute a program. A subject is granted
execute access if the matching ACL entry specifies _e
mode and if the subject's security level dominates
the segment's security level. SL(s) >= SL(o).
null The process cannot access the segment in any way.
(n)
This null access maps into no B&L model access (null
set). A subject is granted no access if the
matching ACL entry specifies no access modes or no
ACL entry matches or if the subject's security level
does not dominate the object's security level. not
(SL(s) >= SL(o)).
_D_i_r_e_c_t_o_r_y _a_c_c_e_s_s _m_o_d_e_s_:
For directories, the mandatory access compatibility rule implies
that SL(o) for a directory always dominates SL(o) for the
10
Multics Security Model MDD-002
containing directory. The ROOT directory is a special case, the
security level of the ROOT is dominated by all security levels.
SL(root) = system low.
status A process granted status access can obtain
(s) information about the attributes of the directory as
well as attributes of segments, directories and
links contained in the directory.
This status access maps into read access in the B&L
model. A subject is granted read access if the
matching ACL entry specifies _s mode and if the
subject's security level dominates the directory's
security level. SL(s) >= SL(o).
modify A process granted modify access can modify
(m) attributes of the directory as well as attributes of
the segments, directories, and links contained in
the directory. Components in the directory can also
be deleted. With the exception: The bit count
attribute is considered part of a segment's
contents, and therefore requires _w access to the
segment whose bit count is to be changed, rather
than _m to the directory. The same is true of the
damaged switch.
This modify access maps into read and write access
in the B&L model. A subject is granted read and
write access if the matching ACL entry specifies _m
mode and if the subject's security level is equal to
the directory's security level. SL(s) = SL(o).
append A process granted append access can create new
(a) directories, segments, and links in the directory.
This append access maps into read and write access
in the B&L model. A subject is granted read and
write access if the matching ACL entry specifies _a
mode and if the subject's security level is equal to
the directory's security level. SL(s) = SL(o).
null A process with no access to a directory can still
(n) reference objects contained in the directory to
which it has non-null access, and read the
attributes of those objects, but cannot reference
any other objects or attributes.
This null access maps into the execute mode of
access for the B&L model. A subject is granted no
access if the matching ACL entry specifies no access
modes or no ACL entry matches or if the subject's
11
MDD-002 Multics Security Model
security level does not dominate the directory's
security level. not (SL(s) >= SL(o)).
_M_e_s_s_a_g_e _S_e_g_m_e_n_t _e_x_t_e_n_d_e_d _a_c_c_e_s_s _m_o_d_e_s_:
When a message segment is created, it is assigned an SLmax(o)
equal to the maximum SL(s) permitted for the creating process
(message segments are multilevel objects). The message segment
implementation ensures that SLmax(o) for the message segment
always dominates SL(o) for any messages placed in the message
segment. The mandatory access compatibility rule ensures, as for
segments, that SL(s) for any reference to the message segment in
any way that SL(s) dominates SL(o) for the containing directory.
Therefore, since SL(o) for a message in a message segment is set
equal to SL(s) for the subject adding it, SL(o) for all messages
in a message segment must dominate SL(o) for the containing
directory.
In addition to the requirements listed below, for all message
segment operations, a process may perform the operation if and
only if: SLmax(segment) >= SL(s) and SL(s) >= SL(dir).
add A process granted add access to a message segment
(a) can add a message.
This add access maps into write access in the B&L
model. A subject is granted write access if the
matching ACL entry specifies _a mode and if the
messages' security level dominates that of the
subject's. SL(o) >= SL(s).
delete A process granted delete access to a message segment
(d) can delete any message.
This delete access maps into read and write access
in the B&L model. A subject is granted read and
write access if the matching ACL entry specifies _d
mode and if the subject's security level is equal to
the message's security level. SL(s) = SL (o).
read A process granted read access to a message segment
(r) can read any message.
This read access maps into read access in the B&L
model. A subject is granted read access if the
matching ACL entry specifies _r mode and if the
subject's security level dominates the message's
security level. SL(s) >= SL(o).
12
Multics Security Model MDD-002
own A process granted own access to a message segment
(o) can read or delete its own messages.
This own access maps into read and write access in
the B&L model. A subject is granted read and write
access if the matching ACL entry specifies _o mode
and if the subject's security level is equal to the
message's security level for deletion or if the
subject's security level dominates the message's
security level for reading. SL(s) = SL(o) for
delete, SL(s) >= SL(o) for read.
status A process granted status access to a message segment
(s) can find out how many messages there are.
This status access maps into read access in the B&L
model. A subject is granted read access if the
matching ACL entry specifies _s mode and if the
subject's security level dominates the messages'
security level. SL(s) >= SL(o).
wakeup A process granted wakeup access to a mailbox type
(w) message segment can send an interactive message to
the mailbox. This mode is valid only for mailbox
message segments.
This wakeup access maps into write access in the B&L
model. A subject is granted write access if the
matching ACL entry specifies _w mode and if the
message's security level dominates the subject's
security level. SL(o) >= SL(s).
urgent A process granted urgent wakeup access to a mailbox
(u) type message segment can send an interactive message
to the mailbox with an urgent wakeup. This mode is
valid only for mailbox message segments.
This urgent wakeup access maps into write access in
the B&L model. A subject is granted write access if
the matching ACL entry specifies _u mode and if the
message's security level dominates the subject's
security level. SL(o) >= SL(s).
null The process cannot access the message segment in any
(n) way.
This null access maps into no B&L model access. A
subject is granted no access if the matching ACL
entry specifies no access modes or no ACL entry
matches or if the subject's security level is not in
the range of the message segment's security level.
13
MDD-002 Multics Security Model
_R_C_P _a_c_c_e_s_s _m_o_d_e_s_:
The ACL for a device is on the RESOURCE_NAME.acs segment for that
device. The ACL for a volume can be found by locating the ACS
segment that applies to the volume in the registry
RESOURCE_TYPE.rcpr. If no ACS segment is in the registry for a
volume, defaults are applied. Free resources known to the system
(inactive) have a security level range specified in the registry
RESOURCE_NAME.rcpr (minimum security level SLmin(o) and maximum
security level SLmax(o)). While active, a resource's security
level is set to the subject's security level (SL(s) = SL(o)) as
long as the subject's security level is within the objects range,
that is, min and max are both set to the subject's level. For
all RCP operations, in addition to the requirements listed below,
the operation may be performed if and only if: SL(s) >= SLmin(o)
and SLmax(o) >= SL(s).
read A process granted read access to a resource can read
(r) the contents of the resource.
This read access maps into read access in the B&L
model. A subject is granted read access if the
matching ACL entry specifies _r mode and if the
subject's security level dominates the resource's
max security level. SL(s) >= SL(o).
write A process granted write access to a resource can
(w) write the contents of the resource.
This write access maps into read and write access in
the B&L model. A subject is granted read and write
access if the matching ACL entry specifies _w mode
and if the subject's security level equals the
resource's security level. SL(s) = SL(o).
executive A process granted executive access to a resource can
(e) change the attributes of the resource; in effect,
grant the same rights to the resource as the
resource owner.
This executive access maps into read and write
access in the B&L model. A subject is granted read
and write access if the matching ACL entry specifies
_e mode and if the subject's security level equals
the resource's security level. SL(s) = SL(o).
null The process cannot access the resource in any way.
(n)
This null access maps into no B&L model access. A
subject is granted no access if the matching ACL
entry specifies no access modes or no ACL entry
14
Multics Security Model MDD-002
matches or if the subject's security level is not
dominated by the resource's security level.
_L_o_g_i_c_a_l _V_o_l_u_m_e _a_c_c_e_s_s _m_o_d_e_s_:
Logical volumes have an access range rather than a single access
level.
read/ A process granted read/write may mount the logical
write volume. Both _r and _w must be present in the ACL
(rw) term of the segment. The subject's security level
must dominate the volume's minimum security level
and be dominated by the volume's maximum security
level. SL(s) >= SLmin(o) and SLmax(o) >= SL(s).
executive A process granted executive access to a logical
(e) volume can change the attributes of the logical
volume as a volume administrator; in effect,
granting the same rights to the resource as the
logical volume owner. The subject's security level
must equal the minimum security level of the volume.
SL(s) = SLmin(o).
null The process cannot access the logical volume in any
(n) way. This null access maps into no B&L model
access. A subject is granted no access if the
matching ACL entry on the corresponding ACS segment
specifies no access modes or no ACL entry matches.
_C_o_m_m_u_n_i_c_a_t_i_o_n _C_h_a_n_n_e_l _a_c_c_e_s_s _m_o_d_e_s
Each communication channel is assigned a minimum SLmin(o) and
maximum SLmax(o) security level, in addition to the current
security level SL(o) it receives while in use.
read/ A process granted read/write access may attach the
write channel and transmit data across it. Both read and
(rw) write must be present in the ACL term of the ACS
segment. The subject's security level must dominate
the minimum security level of the object as well as
be dominated by the maximum security level of the
object. SL(s) >= SLmin(o) and SLmax(o) >= SL(s).
null The process cannot access the channel in any way.
(n) This null access maps into no B&L model access. A
subject is granted no access if the matching ACL
entry on the corresponding ACS segment specifies no
access modes or no ACL entry matches.
15
MDD-002 Multics Security Model
_P_r_o_c_e_s_s _a_c_c_e_s_s _m_o_d_e_s
Processes are treated as objects for interprocess communication.
Each process is assigned a security level, SL(s) for the sending
process and SL(o) for the receiving process. There is no
explicit discretionary control for process objects.
send A process with "send wakeup" access to another
wakeup process may send a wakeup and a 72-bit data message
(w) to that process. The subject's (sending process')
security level must by dominated by that of the
object (receiving process). SL(o) >= S(s).
null The process cannot send a wakeup to the other
(n) process. The process cannot access the channel in
any way. This null access maps into no B&L model
access. A subject is granted no access if the
object's security level does not dominate the
subject's.
_D_I_R_E_C_T_O_R_Y _V_I_S_I_B_I_L_I_T_Y _A_N_D _T_H_E _C_O_M_P_A_T_I_B_I_L_I_T_Y _A_X_I_O_M
In Multics, directories are used to implement the file system
hierarchy. Most objects are contained in directories, including
other directories, and thus the full name of an object is the
object name itself concatenated with the names of all the
containing directories.
Because null access to directories maps into the "execute" mode
of the model, a subject may exercise access rights to an object
regardless of the access rights to containing directories. Thus,
it is possible for a subject to sense, indirectly, the existence
of intermediate directories within the name of an object, even if
the directories are otherwise inaccessible, because the object
itself is accessible.
The "compatibility" restriction on directories requires that a
directory contain non-directory objects only at the same level as
the directory, and directory objects at that level or above.
Consequently, if the directory is at a security level
inaccessible to the subject, all objects contained in the
directory, or in other directories contained in the directory,
are guaranteed also to be inaccessible, and therefore there is no
way to infer the existence of a directory that is inaccessible
due to the mandatory security policy.
-----------------------------------------------------------
Historical Background
This edition of the Multics software materials and documentation is provided and donated
to Massachusetts Institute of Technology by Group BULL including BULL HN Information Systems Inc.
as a contribution to computer science knowledge.
This donation is made also to give evidence of the common contributions of Massachusetts Institute of Technology,
Bell Laboratories, General Electric, Honeywell Information Systems Inc., Honeywell BULL Inc., Groupe BULL
and BULL HN Information Systems Inc. to the development of this operating system.
Multics development was initiated by Massachusetts Institute of Technology Project MAC (1963-1970),
renamed the MIT Laboratory for Computer Science and Artificial Intelligence in the mid 1970s, under the leadership
of Professor Fernando Jose Corbato. Users consider that Multics provided the best software architecture
for managing computer hardware properly and for executing programs. Many subsequent operating systems
incorporated Multics principles.
Multics was distributed in 1975 to 2000 by Group Bull in Europe , and in the U.S. by Bull HN Information Systems Inc.,
as successor in interest by change in name only to Honeywell Bull Inc. and Honeywell Information Systems Inc. .
-----------------------------------------------------------
Permission to use, copy, modify, and distribute these programs and their documentation for any purpose and without
fee is hereby granted,provided that the below copyright notice and historical background appear in all copies
and that both the copyright notice and historical background and this permission notice appear in supporting
documentation, and that the names of MIT, HIS, BULL or BULL HN not be used in advertising or publicity pertaining
to distribution of the programs without specific prior written permission.
Copyright 1972 by Massachusetts Institute of Technology and Honeywell Information Systems Inc.
Copyright 2006 by BULL HN Information Systems Inc.
Copyright 2006 by Bull SAS
All Rights Reserved