Lecture08.tex

% Lecture 8: 10 October 2012
% System and software security - done with Crypto
\sektion{8}{Access control}
How you reason about and enforce rules about who's allowed to do what in the
system. 
\\
\\
Secure system design = secure components + isolation + access control.
\\
\\
This deals with authentication (Who is asking?), not authorization (Does that
person have permission?).
\\
\\
Two authorization approaches:
	\begin{itemize}
	\item access control matrix/list
	\item capabilities
	\end{itemize}

\begin{definition}{Trusted subsystem}\\
A program, with state, that is \underline{isolated} from
the rest of the world, and interacts via \underline{declared interfaces}
\end{definition}

Access control: SUBJECT wants to do VERB on OBECT. Okay?

Policy: a set of (S,V,O) triples that are allowed
\begin{itemize}
    \item How to determine policy? (\underline{should})
    \item How to enforce policy? (\underline{is})
\end{itemize}
One data structure: Access Control Matrix\\
\parbox[c]{5cm}{\makebox[5cm]{$\longleftarrow$ objects $\longrightarrow$}\\
\parbox[c]{1cm}{$\uparrow$\\
\begin{sideways}subjects\end{sideways}\\
$\downarrow$}
\makebox[.5cm]{}
\fbox{$V_1, V_2$}}

\subsektion{Subjects and labels}
\begin{itemize}
    \item subject = some process
    \item Object is some resource (file, open network connection, window)
    \item often, give labels to subjects and set policy based on labels
    e.g. label a process with a user id\\
    (+) reduces matrix size\\
    (+) easier to make policy based on labels\\
    (--) oversimplifies? Suppose: label = userid and means program is running
    ``for'' userid. Alice runs a program written by Bob (example: Alice uses a
        text editor written by Bob to edit Alice's secret file). What label?
    \begin{itemize}
        \item If treat as Alice: Bob's code can send Alice's secret data to Bob
        \item If treat as Bob: Alice can't edit her secret file, can read Bob's files
        \item If treat as Bob but special for this file: none of the labelling
        benefits
        \item If treat as intersection of privileges: get all the drawbacks
    \end{itemize}
    \item Common approach in OS (e.g. Linux): setuid bit
   	 \begin{itemize}
    	\item Bob decides whether program runs as himself or invoker
    	\end{itemize}
\end{itemize}
Store access control info:
\begin{itemize}
    \item as AC matrix - note that this will be very sparse
    \item as ``profiles'' - for each user, list of what subject can do (i.e. row of AC matrix)
    \item as Access Control List (ACL) - for each object, list of (Verb,
            Subject) pairs (who can do what to it). This is typically used
    because small and simple in practice. Often, ACL are stored along with object.
\end{itemize}
Who sets policy?
\begin{itemize}
    \item centralized (``mandatory'') - done by an authority

    (+) done by a well-trained person\\
    (+) might be required (ethical, legal, or contractual obligations)\\
    (--) inflexible, slow
    \item decentralized (``discretionary'') - each object has an
    \underline{owner}, owner set ACLs

    (+) flexible\\
    (--) every user makes security decisions (mistake-prone)
    
    \item mix - owner can choose, within limits set by centralized authority
\end{itemize}
Groups and Roles:\\
Group is a set of people with some logical basis; role is group with one
member\\
Advantages:
\begin{itemize}
    \item makes ACL smaller, easier to understand
    \item change in status naturally causes change in access to resources
    \item ACL encodes reason for access in system (i.e. why you have access)
\end{itemize}
Roles can be hidden temporarily, ``wearing different hats'' (useful for testing)

\subsektion{Traditional Unix File Access}
File belong to one user, one group. 
\\
\\ ACL for each operation contains subset of $\{\text{user}, \text{group}, \text{everyone}\}$. Every VERB requires 3 bits for each operation. 
\\
\\
Every file also has a setuserid bit. 
\begin{itemize}
	\item treat as file owner if setuid = true
	\ item treat as invoker if setuid = false
\end{itemize}

\subsektion{Capabilities}
A different approach to access control: controls access without identification,
like a physical key, ``the bearer has permission to do VERB on OBJECT.''

Sometimes make them revokable, but that's a pain to do in practice

Implementation: crpytographic
\begin{enumerate}
    \item system has a secret key $k$, capability = MAC($k$, verb || object)
    \item public-key: one party grant permission (makes digital signature),
    another party control access (makes sure handed valid capability - verifies
    signature)
\end{enumerate}
Implementation: OS table\\
OS stores a list of your capabilities; Alice makes a system call to give Bob
capabilities for a certain file (file descriptors used to say you've an open
file are an example)

Implementation: in a type-safe programming language (like Java), pointer to an
object is a capability
\\
\\
Tradeoffs:
\begin{itemize}
    \item cryptographic

    (+) totally decentralized \\
    (--) if capability leaks, big trouble\\
    want some kind of revocation, but hard to do
    
    \item OS table
    
    (+) can control flow of passage of capabilities\\
    (+) revocation is much easier\\
    (--) centralized, requires overhead, lack of flexibility, 
\end{itemize}

\subsektion{Logic-based authorization}
Define a formal logic, with primitives for
\begin{itemize}
    \item principals (e.g. users/groups)
    \item objects
    \item delegation
    \item time
\end{itemize}
To get access, submit a proof that you are authorized

Parties make statements by digital signing

System allows for great complexity in policies, but only need simple proof-
checking mechanism to make it work. But also need to work out a way to get
people able to write these statements, and deal with possible large proof size

Caveat: people don't actually use complicated access control mechanisms, and
usually just leave them as the defaults or make it visible to the whole world

Want to come up with a system which infers what the user wants from the way the
user behaves (best if not visible to user)
>>>>>>> 8e525b42b773087a879a1983645b17cc93ee0bb7