\documentstyle[12pt,pocs-header]{article}
\Scribes{Jennifer Wu and Raymie Stata}
\Lecturer{Butler Lampson}
\LectureNumber{18}
\LectureDate{19 November 1990}

\begin{document}
\MakeScribeTop

\section{Handouts}

\begin{center}
\begin{tabular}{|c|l|} \hline
\multicolumn{1}{|c|}{Handout} &
\multicolumn{1}{c|}{Title} \\ \hline
35 & Requirements and technology for \\
   & computer security \\ \hline
\end{tabular}
\end{center}

\section{Introduction}

In security, we are concerned with ensuring that a system behaves
according to its spec in the presence of a malicious adversary trying
to make the system fail.  The emphasis is on the former rather than
the latter, 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.

\section{Policy}

First step in designing secure system is defining a security {\it
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{itemize}
\item {\it Secrecy:} controlling who gets to read information;
\item {\it Integrity:} controlling how information changes;
\item {\it Availability:} controlling the ability to deny access to
information.
\end{itemize}

Importance of each category varies with the system.  In the security
literature, a disproportionate amount of work has gone into secrecy,
and the other categories tend to get blurred.  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{Models}

Policy deals with the entire information handling system; a security
{\it model} is the formal spec for the computer part of the policy.  There
are two popular models: flow and 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{Flow}

Flow models are 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; 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}
\label{sc:acm}

The access control model assumes that all objects are protected by
{\it reference monitors} (or ``guards'') 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 principals 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}
Principal & \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}
\end{center}
\caption{\label{fg:matrix}Access control matrix}
\end{figure}

We'll see more about implementing this model later.


\section{Security Services}

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

\begin{itemize}
\item {\bf Authentication}: determine who (what principal) 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.
(Researchers would like to develop an expert system to automatically
detect suspicious activity from the audit log, but they haven't been
too successful yet.)  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.

\item {\bf Recovery}: restore system after a security breach.
\end{itemize}


\section{Implementation of Security Systems}

A secure system based on the access control model has two major
mechanisms to be implemented:
\begin{itemize}
\item {\bf Secure channel:} the path between a subject and an object.
It is called a ``channel'' because data flows back and forth between
the two ends; it is called ``secure'' because we know who is on each
side of the channel (authentication).  Secure channels will be the
subject of a future lecture.

\item {\bf Reference monitor:} ensure that objects are protected such
that subjects can only perform the operations that the security policy
says they are allowed to perform (authorization).  The reference
monitor will be discussed in Section~\ref{sc:refmon}.
\end{itemize}


\section{Assurance}

Once we've built a system, we want {\it assurance} that it actually
satisfies its security model.  One way of doing that is to do
a correctness proof on the system.  However, to do these proofs
correctly we not only have to prove the correctness of our own code
but we have to prove the correctness of all the levels of abstraction
below our code (e.g., CPU's, compilers).

This is a daunting task, but it is necessary; Ken~Thompson, programmer
at Bell Labs, pulled a hack to prove it.  He wrote a version of the
Unix C compiler that, when it compiled the Unix source code, would
insert code to give his user name super-user privileges.  He then
wrote a version of the C compiler that, when it compiled the plain C
compiler source, inserted the code that would modify the Unix kernel.
If you looked at the cc and Unix sources, you couldn't tell anything
was wrong; but when you compiled the cc source with the compiler
binary distributed with the release, then compiled the Unix kernel with
the resulting compiler (a common practice), the result was a trap-door.

A tiger team at Honeywell played a similar trick at the hardware
level.  Somehow they obtained the blue prints for the system and
worked out some wire changes that would cripple the hardware
superviser protection mechanism.  They also obtained official
Honeywell engineering change-order forms and made a change-order
to install this modification.  They then simply mailed the
change-order to the site, and a few weeks latter the system was no
longer secure.

Yet another story: people in some intelligence agency figured out that
anyone should be able to eavesdrop on electrodynamic combinations of
computer systems, since back in those days outputs were produced on
mechanical wire printers.  So this group of people figured out a way
to get copies of outputs being printed at least a quarter of a mile
away.  Then one day they brought the machine to the parking lot of one
of their rival agencies and eavesdropped on what was being printed out
in that agency.  They waited until some important message or document
was coming out and made a copy of it.  Then they laid that copy on the
desk of the head director of that rival agency.

The point of all these stories is that in practice we should make the
part of the system which has to work in order to meet the
specification of a secure system, as small and as simple as possible.
Then we can convince ourselves that the part is good.  Normally we
call such part a kernel.  If the kernel works correctly, then we can
say that the system is reasonably secure.  As to the other much larger
part of the system, all we need to know is that it also has to work
correctly in order for the system to do some useful things.  But that
is not a concern as far as security goes.


\section{Reference monitor}
\label{sc:refmon}

The reference monitor needs a representation of the protection matrix
described in Section~\ref{sc:acm}.  There are two common
representations: {\it access control lists} and {\it capability
lists}.

\subsection{Access control list}

The access control list (ACL) approach represents the matrix by its
columns, i.e. for each object we list what principals may perform
what operations.  An ACL is a list of names paired with the name's
access rights to the object.  The ACL is commonly attached to the
object itself; the reference monitor and the operations to update the
ACL are built right into the object's operations.


\subsection{Capability list}

It is organized by the rows of the matrix, i.e. for each name we list
what operations it may perform on what objects.  Like ACLs, cap-lists
are usually attached to each subject; unlike ACLs, however, 
the operations to maintain the cap-list are not built into the subject
because we don't trust the subject to give itself privileges.


\subsection{ACLs vs. cap-lists}

Since it is the objects that we are trying to protect, and since
objects have an interest in protecting themselves, there is no need to
make a distinction between mechanisms that implement ACL's and
mechanisms that implement objects.  As hinted earlier, however, if we
attach cap-lists to subjects, we cannot trust the subject to give
himself privileges so we need an external mechanism to maintain the
lists.  Other than that, ACL and capability lists should be quite
symmetrical in terms of behaviors.

ACLs are easier to maintain in systems with lots of objects or systems
that need a finegrain of granularity, i.e. protecting individual
operations independently.  This is because again it is objects that
we are trying to protect.  (Increasing the granularity of protection
has many trade-offs in its own right.  Obviously, it increases the
amount of protection information that has to be maintained.  Further,
as granularity gets smaller it gets harder to determine exactly what
access privileges a subject needs.)

ACLs also make auditing easier: an object's ACL gives directly the
list of subjects that have access to it.  With cap-lists, determining
who can access an object requires a search that can be expensive,
especially in a distributed system.  (Of course, cap-lists make it
easier to determine the privileges of a given subject, but this
information is less important than the other.)

Unfortunately, ACLs require a lookup on each reference to a protected
object, making object references expensive.  The promise of capability
lists was to eliminate the overhead of protection with special
hardware.  The hardware would contain special ``capability'' registers
that, in effect, contains the current processes's cap-list.  
Whenever the process made a reference, the hardware would concurrently
execute the reference and check the cap-registers to see if the
process is authorized to make the reference; if it was not authorized,
the hardware would fault.

While the hardware-oriented, cap-list mechanism has found success in
specialized areas (e.g., memory protection), it has not proven to be a
good general purpose mechanism.  Basically, the overhead of special
registers, special segments to hold cap-lists, and the expense of
checking on each memory reference is too much to make it worth-while.

Typically, most applications use the ACL mechanism with a
cap-list-inspired tweak.  When the reference monitor looks up a
subject's principal in an ACL and decides that the subject has the
necessary permissions, it gives the subject a ``token'' or
``capability'' that will allow it to perform the operation.  The
subject can then perform the operation several times without having to
be looked up again.  Eventually, however, the token expires and
subsequent accesses go back to the ACL.  This technique in effect
catches the results of ACL lookups.


\section{Setting up ACLs}

When a person puts on his ``user'' cap, security becomes an
obstacle to getting useful work done.  If we don't make security
``user-friendly''---i.e. expressive yet straight forward---then users
will probably subvert the security system.  Good naming is an
important aspect of user-friendliness.

Internally, principals are typically named by integer-encoded UIDs.
However, this kind of naming is not very user-friendly, so systems
provide a service to map text-encoded user-names to UIDs.  In such
systems, it's very important to make the mapping process secure.

Groups names are an abstraction of user-names (i.e., a collection of
individual names is named by a single, group name) that increase the
user friendliness of naming.  For instance, we might want to give the
TAs of a class permission to access class files; with groups changes
in TAs are easy to handle since only one list needs to be updated.
(We do have to pay the price of following through another level of
indirection and the space to store these pointers.)  A symmetric idea
is to use a common ACL for more than one object.

\end{document}