\include{macros}
\documentstyle[12pt,pocs-header]{article}
\Scribe{Kah-Kay Sung}
\Lecturer{Butler Lampson}
\LectureNumber{22}
\LectureDate{2 December 1991}

\begin{document}
\MakeScribeTop

\section{Handouts}

\begin{center}
\begin{tabular}{|c|l|} \hline
\multicolumn{1}{|c|}{Handout} &
\multicolumn{1}{c|}{Title} \\ \hline
42 & Requirements and Technology for Computer Security \\
43 & Authentication in Distributed Systems:  Theory and Practice \\
44 & Problem Set 8  (Ugh !!!) \\ \hline
\end{tabular}
\end{center}

\section{Introduction}

This lecture deals with {\bf Security} issues in computer systems.  Like
other computer systems design issues, security issues include two main
aspects, namely (1) Specification and (2) Implementation.  In security,
we are concerned with ensuring that a system behaves according to its
specification in the presence of a malicious adversary trying to make
the system fail.  The emphasis is on the latter rather than on the
former, i.e. security is not so much concerned with the system behaving
according to the spec (that's a much broader concern covered by software
engineering as a general practice) but with making sure that the
adversary can't interfere.

\subsection{Some Informal Points on Security}

Two comments on the topic of security before we move on:

\begin{enumerate}

\item
The {\em security} component of a computer system usually makes up only
a small portion of the entire system.  Perhaps the best way to reason
about a system's secure behaviour is to factor out other aspects of the
system, so that the security aspect can be analyzed in isolation.  Much
of this trade has to do with determining and identifying system parts
that are important or relavant to the system's overall secure behaviour.
We shall discuss some common strategies that people have used in
performing these ``cuts''.

\item
The overall notion of system {\em security} is not just limited to the
computer system's secure behaviour alone.  Top level security policies
deal with other external factors as well, like adversaries tapping
communication channels, physical sabotage and safeguarding system access
priviledges.  The system's actual secure behaviour only makes up part of
the entire security scene.

\end{enumerate}

\subsection{Specification and Implementation}

Normally, we use {\em Policies} and {\em Models} to {\em specify}
security standards.  We shall describe these notions in greater detail
shortly.  

A system's secure {\em implementation} is centered on a set of items
called the {\bf Trusted Computing Base} (or {\bf TCB} for short),
sometimes also known as the {\bf Kernal}.  The {\bf TCB} is the set of
all system components that if working correctly, guarantees the system's
secure behaviour according to spec.  One approach to implementing
tractable security systems is to keep the {\bf TCB} as small as possible
in size.

\section{Security Policy}

The first step in designing a secure system to define a security {\em
policy} for the entire information handling system; that is, a set of
rules by which people are given access to read and change information.
Generally, policy concerns fall into three categories:
\begin{enumerate}
\item {\bf Secrecy:} controlling who gets access to information;
\item {\bf Integrity:} controlling the nature of state and information
changes that the system is allowed to make;
\item {\bf Availability:} controlling the ability to allow legitimate
access to information even while there are hostile intrusion attempts.
\end{enumerate}

The importance of each category varies with the system.  In security
literature, a disproportionate amount of work has gone into secrecy, and
the other categories tend to get obscured.  This is because the military
has been the largest sponsor of security research, and its main concern
is secrecy.  The main concern of commercial systems, however, is
integrity.


\section{Security Models}

Policy deals with the entire information handling system; a security
{\it model} is the formal specification for the computer part of the
policy.  There are two popular models: {\em information flow} and {\em
access control}. 

(In the following discussion, an object is a piece of data to be
protected, a principal is a person, group of people, or system to whom
authorization to access objects is either granted or denied, and a
subject is a process running on behalf of some principal.)

\subsection{Information Flow Model}

Flow models are suitable for specifying large computing environments
with lots of shared software and databases, where there is no simple way
of ensuring the integrity of all system data and applications.  The
model is based on a lattice of security levels.  In military
applications, security levels are made of two components:  an access
level (one of top secret, secret, confidential, and unclassified) and a
set of compartments (e.g. NATO, crypto, nuclear).  These levels are
ordered by access level first and then by compartment (compartments are
ordered by subset inclusion).

In theory, each variable and each subject in a flow model system is
tagged with a security level.  A subject may only read from an object
with a security level equal to or less than its own, and may only write
to an object with a equal or greater level.  When multiple objects are
operated on or combined, the output inherits the highest security level
among the input objects.  For example, the output of an application that
reads a {\em secret} object and a {\em confidential} object must be
classified as {\em secret}.  Thus, information can only flow up the
lattice.

In practice, only gross objects such as files and communication
channels are labeled with security levels.  The handling of
communication channels is not very graceful.  


\subsection{Access Control Model}
\label{sc:acm}

Figure~\ref{fg:access} shows the components that make up an Access
Control Model of system security.  The model consists of an {\em agent}
and a {\em resource}.  (In formal terms, they are known as {\em subject}
and {\em object} respectively).  The subject issues {\em requests} that
access or change information at the object.  In real life, some
\mbox{\tt [Subject, Object, Request]} examples are: (1) {\tt [User,
File, Read/Write requests]} in a file server setting, and (2) {\tt
[Customer, Teller Machine, Withdrawl/Deposit requests]} in a banking
system.

\begin{figure}
%\fbox{ \begin{minipage}[b]{6.25in}
\centerline{\psfig{width=6in,figure=acm.idraw}}
\caption{Access control model components.}
\label{fg:access}
%\end{minipage}}
\end{figure}


The Access Control Model assumes that all objects are protected by {\em
guards} (or more formally, {\em reference monitors}) that grant or deny
access to the object.  (The correctness of this model relies on the
assumption that the only way to gain access to an object is through its
reference monitor.)  Privilege information can be summarized by a
matrix: along one axis of the matrix are the subjects in the system, and
along the other axis are the objects in the system.  Each entry of the
matrix contains the subject's {\it privileges} or {\it access rights}
for the object, i.e. each entry lists the operations that the subject
may make on the object (see Figure~\ref{fg:matrix}).

\begin{figure}
\begin{center}
\begin{tabular}{c|cccc}
Subject & \verb+/etc/passwd+ & printer & \dots & Bow gun 4 \\
bush    & \{R\}              & \{R,W\} & \dots & \{Aim, Fire\} \\ 
lampson & \{R\}              & \{R,W\} & \dots & \{Aim\} \\
\vdots  &                    &         &       &      \\
weihl   & \{R\}              & \{R,W\} & \dots & \{\} \\
\end{tabular}
\caption{Access control matrix}
\label{fg:matrix}
\end{center}
\end{figure}



\section{Security in Distributed Systems}

% Characteristics

The following are some special characteristics of distributed systems
that make security issues more complex than those of local systems:

\begin{itemize}

\item
{\bf Big: } Distributed systems can be arbitrarily large in size, so the
security system must be scalable.

\item
{\bf Strung out: }  Requests between {\em subject} and {\em object} may
pass through many intermediate channels and machines.

\item
{\bf Heterogeneous: } Software, machine architectures and local
management can be very different at different sites of a distributed
system.  The security system must be simple and flexible enough, so all
sites can conform to its requirements.

\item
{\bf Partly broken: }  There is no guarantee that all sites are
functioning correctly at any time.  So the security system must be able
to tolerate some local site failures.

\end{itemize}

\subsection{Abstracting the Problem}

Figure~\ref{fg:distrib} shows an extended Access Control Model for
reasoning about the secure behaviour of distributed systems.  At top
level, its structure is similar to the basic Access Control Model for
local systems, in that it consists of a {\em subject} issuing {\em
requests} to an {\em object}.  The difference is at the bottom level,
where we must also be concerned about the channel's secure behaviour
(ie. network security).

\begin{figure}
%\fbox{ \begin{minipage}[b]{6.25in}
\centerline{\psfig{width=6in,figure=extacm.idraw}}
% Use diagram listed quoted as example motivation.

\caption{Extended access control model for distributed
systems.} 
\label{fg:distrib}
%\end{minipage}}
\end{figure}

A secure distributed system based on the Access Control Model must
therefore have the following two major mechanisms:

\begin{enumerate}
\item {\bf A reference monitor:} To ensure that objects are protected
such that subjects can only perform the operations that the security
policy says they are allowed to perform (authorization).  (See
Subection~\ref{sc:acm}).

\item {\bf A secure channel:} A channel is a physical path between a
subject and an object, where data flows back and forth between the two
ends.  A channel is ``secure'' if we know who is on each side of the
channel (authentication).  Secure channels will be the subject of a
future lecture.

\end{enumerate}



\subsection{Security Services}

The following security services are used in implementing secure
distributed systems (this list is biased towards the access control
model):

\begin{itemize}
\item {\bf Authentication}: Determine who, or what {\em principal} (see
Subsection~\ref{sc:term}) is making the request.

\item {\bf Authorization}: Decide if the principal making the request
has the privilege to perform the requested operation (this is done by
the reference monitor).

\item {\bf Auditing}: Record interesting events as an extra level of
protection.  If we suspect that the system has been compromised, we can
use the information in the audit log to confirm the suspicion.  Also, if
something has gone wrong, we can use the audit log to recover the system
and to find out how to protect from a similar breach.  Finally, in the
commercial world the audit-log can be used in legal action against those
that violate a system.

\end{itemize}

\section{A Semantics for Secure Channels}


In order to discuss issues of authentication, we must be able to say
something about who can send messages and how messages can be conveyed.
We begin with some formal terms that we shall use in this analysis:

\subsection{Terminology}
\label{sc:term}

\begin{itemize}

\item A {\em principal} is said to be an entity that is allowed to 
make {\em statements}.  A principal is a subject in the Access Control
Model and may be a single user, such as Bob, or an aggregate set of
users, such as Bob and Alice, or the users on the fifth floor of 545
Tech Square.  The principal may even be an application or a system that
is being run by another principal.

\item A {\em statement} can be thought of as a request.  A 
statement can mean ``print the contents of file x to my terminal'' or 
``start program y and concatenate the results onto file z''.

\item A {\em channel} is some method by which a principal makes a 
statement.  A channel can be physical, such as a wire, or more
abstract such as a network.

\end{itemize}

\subsection{Language Primitives and Constructs}

We introduce some primitives to help us describe the mechanics of
authentication.  

\begin{itemize}

\item
{\tt P  says S: } We use this primitive to indicate that principal
{\tt P} makes statement {\tt S}.

\item
{\tt A speaks for B: } This primitive shows the relationship between two
principals.  It means:  {\tt $\forall$S: A says S $\Rightarrow$ B says
S}.  Here are some examples illustrating the {\tt speaks for} concept:
(1) A principal {\tt P} that is a member of a group {\tt G} (also a
principal) may {\tt speak for} the group.  (2) A channel may {\tt speak
for} a person, both of which are principals.  Henceforth, we shall use
the notation:  \mbox{\tt A $\Rightarrow$ B} to denote the ``{\tt A
speaks for B}'' relationship.

\end{itemize}

With these primitives, we can construct more complex {\em principals},
{\em statements} and relationships.  The following example shows how
principals can be combined what it logically means.  {\tt A} and {\tt B}
are principals and {\tt S} is a statement:

\begin{eqnarray*}
(\mbox{\tt A}\wedge\mbox{\tt B}) \mbox{\tt says S} \equiv \mbox{\tt A
says S} \wedge \mbox{\tt B says S}. 
\end{eqnarray*}

\noindent
Here is another way of expressing the {\tt speaks for} relationship:

\begin{eqnarray*}
\mbox{\tt A} \Rightarrow \mbox{\tt B} \equiv (\mbox{\tt A} = (\mbox{\tt
A} \wedge \mbox{\tt B})). 
\end{eqnarray*}

\noindent
Our final example illustrates the {\em quoting} mechanism, indicated by
the ``{\tt |}'' symbol:

\begin{eqnarray*}
\mbox{\tt A|B says S} \equiv \mbox{\tt (A says (B says S))}. 
\end{eqnarray*}

\noindent
We can think about the {\em quoting} mechanism in the context of
multiplexing channels as follows:  Suppose principal {\tt A} is the
gateway for principal {\tt B} to a certain network.  Then ``{\tt A|B
says S}'' describes the act of {\tt A} transmitting one of {\tt B}'s
statements onto the network.

\subsection{The Handoff Axiom}

This axiom is useful for helping us infer where statements (requests)
actually originate from, given a set of {\tt speaks for} relationships:

\begin{eqnarray*}
\mbox{If {\tt A says (B}} \Rightarrow \mbox{{\tt A)} then {\tt (B}}
\Rightarrow \mbox{\tt A)}. 
\end{eqnarray*}

\noindent
We can derive the following rule using the above {\bf Handoff Axiom} and
the {\tt speaks for} rule:

\begin{eqnarray*}
\mbox{If {\tt A'}} \Rightarrow \mbox{\tt A} & \mbox{and} & \mbox{\tt A' says B}
\Rightarrow \mbox{\tt A} \\
 & \mbox{then} & \mbox{\tt B} \Rightarrow \mbox{\tt A}.
\end{eqnarray*}

\section{Secure Channels}

We end with a brief introduction to {\bf secure channels}, which we
shall elaborate further in the next lecture.  Channels provide a means
for {\em principals} to make {\em statements} or for one principal to
communicate with another.  The abstraction can include:

\begin{itemize}
\item
A physical medium such as a wire, a disk drive, etc.

\item Calls to the operating system kernal.

\item A network.
\end{itemize}

A {\em secure} channel has two essential characteristics:

\begin{enumerate}
\item
{\bf Secrecy: } The ability to restrict where a message can be received.

\item
{\bf Integrety: } The ability to determine with certainty where a
message could have originated from.

\end{enumerate}

\noindent
It can be dangerous to assume that channels are secure as they are,
especially for networks, so protection means like {\em data encryption}
are necessary.

\end{document}