\documentclass{ictlab}

\RCS $Revision: 1.12 $

\usepackage{alltt,key,color,answer2}
\usepackage[bf,flushleft]{caption2}
\ifx\pdftexversion\undefined \else
  \usepackage[pdfpagemode=None,pdfauthor={Nick Urbanik}]{hyperref}
\fi

\renewcommand*{\subject}{Operating Systems and Systems Integration}

\newcommand*{\labTitle}{Access Control \& Permissions: SUID, SGID,
  \texttt{chmod}, \texttt{chown}, and \texttt{chgrp}}

\definecolor{light-blue}{rgb}{0.4,0.4,1}
\newcommand*{\gl}[1]{\textcolor{light-blue}{#1}} % good link
\newcommand*{\ex}[1]{\textcolor{green}{#1}} % executable file
\newcommand*{\bl}[1]{\colorbox{red}{\textcolor{white}{\textbf{#1}}}} % bad link

\begin{document}

\section{Aim}
\label{sec:aim}

This short exercise is a quick introduction to the use of the tools
\texttt{chmod} (\emph{change mode}), \texttt{chown} (\emph{change
  owner}), and \texttt{chgrp} (\emph{change group}).  It also aims for
you to understand the access control permissions, including \emph{set
  user \ID} (\SUID) and \emph{set group \ID} (\SGID) through some
practical exercises.


\section{Background}
\label{sec:background}

\subsection{Access Control to Files: the Rules}
\label{sec:access-control-rules}
\begin{figure}[htb]
  \centering%
  \includegraphics[width=\textwidth]{ls-l-output}
  \caption{The output of \texttt{ls -l}: what each field is.}
  \label{fig:ls-l-output}
\end{figure}
File permissions are shown when you list a file's details with the
command \texttt{ls~-l}; see figure~\vref{fig:ls-l-output}.
Permissions are divided into three sets, as shown in
figure~\vref{fig:permissions}.

\begin{figure}[htb]
  \centering%
  %\includegraphics[scale=0.25]{permissions}
  \begin{minipage}[c]{0.45\linewidth}
    \caption{There are three sets of of permissions: one for the user that
      owns the file, one set for the group that owns the file, and the
      last set for all other users who are not the owner of the file,
      not members of the group that owns the file.}
  \label{fig:permissions}
  \par\vspace*{0pt}%
  \end{minipage}%
  \hspace*{0.02\linewidth}%
  \begin{minipage}[c]{0.45\linewidth}
  \includegraphics[width=\linewidth]{perms}
  \end{minipage}
\end{figure}

The rules that determine your access rights to a file are quite
simple:
\begin{enumerate}
\item if your user \ID is the same as the \textbf{u}ser that owns the
  file, then the left-most read, write, execute permissions on the
  file apply to you.
\item Otherwise, if you belong to the \textbf{g}roup that owns the
  file, then the middle three read, write, execute permissions on the
  file apply to you.
\item Otherwise, the right-most read, write and execute permissions on
  the file apply to you.
\end{enumerate}
Example: Suppose we have three users as shown in this table:\\[1ex]
\noindent%
\begin{tabular}[t]{@{}>{\ttfamily}l>{\ttfamily}l>{\ttfamily}l@{}}
\toprule%
\textnormal{\textbf{Username}} &
\multicolumn{2}{c}{\textnormal{\textbf{Belongs to these groups}}}\\
\midrule%
nicku & nicku & staff \\
henryl & henryl & staff \\
a1 & a1 & students \\
\bottomrule
\end{tabular}\\[1ex]
Suppose that the following files have these permissions and ownership:
\begin{alltt}
$ \textbf{ls -l}
----r--r--    1 nicku    root         4022 Oct  9 22:05 wgetrc
drwxr-x---   17 root     henryl       4096 Aug 28 12:43 X11
-rw-r-----    1 root     staff         289 Nov 20 01:00 xinetd.conf
drwxr-x--x    2 root     root         4096 Dec  5 01:43 xinetd.d
drwxr-xr--    2 root     nicku        4096 Jul  3 01:07 xml
-rw-r--r--    1 nicku    nicku        4941 Mar 19  2002 xpdfrc
-rw-rw-rw-    1 root     root          361 Mar 26  2002 yp.conf
-rw-r-----    1 root     root         1626 Oct  8 01:56 ypserv.conf 
\end{alltt}%$
Then for each file or directory, each user has the following
access rights:\\[1ex]
\noindent%
\begin{tabularx}{\linewidth}{@{}>{\ttfamily}lXXX@{}}
\toprule%
\textnormal{\textbf{file}} & \texttt{\textbf{nicku}} &
\texttt{\textbf{henryl}} & \texttt{\textbf{a1}}\\
\midrule%
wgetrc      & no access & read & read \\
X11         & no access & read, can change into the directory & no
access \\
xinetd.conf & read & read & no access \\
xinetd.d    & \multicolumn{3}{c}{can change into the directory, but not list it.}\\
xml         & list, change into & \multicolumn{2}{c}{list with
  \texttt{ls}, not \texttt{ls -l}}\\
xpdfrc      & read, write & \multicolumn{2}{c}{read} \\
yp.conf     & \multicolumn{3}{c}{read, write} \\
ypserv.conf & \multicolumn{3}{c}{no access} \\
\bottomrule
\end{tabularx}

\subsection{Meaning of Read, Write, Execute Permissions on a
  Directory}
\label{sec:directory-rwx}

Directories are files that contain a list of data for each file:
filename, \emph{inode number}.  The directory does not contain other
information about the file, such as the size, the time it was last
modified, \ldots.  The \emph{inode number} is just a number that
uniquely identifies where on the disk partition the file contents are
actually stored.  We will discuss inode numbers in the module on
filesystems in the workshop notes.


\paragraph{read permission}

in a directory means that you can list the file names in the directory
with commands such as \texttt{ls}.

\paragraph{write permission}

on a directory means the right to delete a file from the directory.
Note that the right to delete a file does not depend on the permissions
on the file itself, only on the directory in which the file is
located.

\paragraph{execute permission}

on a directory allows changing into that directory with a \texttt{cd} command.

\subsection{Minimum Permissions Required for some Operations}
\label{sec:minimum-permissions}

  \begin{tabular}[t]{@{}>{\ttfamily}lcc@{}}
    \toprule%
    \textnormal{Command} & \multicolumn{2}{c@{}}{minimum access required}\\
    \cmidrule(l){2-3}%
    & on the file & on the directory\\
    \midrule%
    cd /var/project & no file & \texttt{--x}\\
    ls /var/project & \texttt{---} & \texttt{r--}\\
    ls -l /var/project & \texttt{---} & \texttt{r-x} \\
    cat /var/project/user1.txt & \texttt{r--} & \texttt{--x} \\
    echo "hello" >> /var/project/user1.txt & \texttt{-w-} &
    \texttt{--x} \\
    /var/project/binary-program & \texttt{--x} & \texttt{--x} \\
    /var/project/script-program & \texttt{r-x} & \texttt{--x} \\
    rm /var/project/user1.txt & \texttt{---} & \texttt{-wx} \\
    \bottomrule
  \end{tabular}


\subsection{The Set User ID and Set Group ID Permissions}
\label{sec:suid-sgid}

Every process has a user \ID that owns the process, and a group that
owns the process.

When you execute a program, the owner of the process is equal to your
user \ID, and the group that owns the process is equal to your primary
group \ID.  

If you execute a program file that has the \emph{set user \ID}
permission, the process will probably execute with a different user
\ID from yours.

If you execute a program file that has the \emph{set group \ID}
permission, the process will most likely execute with a different
group \ID from yours.

The aim of these exercises is to find out what determines the user
\ID of a process started from a \SUID executable file, and what
determines the group \ID of a process started from a \SGID file.


\subsection{Who owns a process?}
\label{sec:ownership-of-process}

How can you tell who owns a process?  The \texttt{ps} command can tell
you: \texttt{ps -eo user,group,cmd}.  This will show \emph{all}
processes.  To filter out all but \texttt{/tmp/ash}, you could do:
\texttt{ps -eo user,group,cmd | grep /tmp/[a]sh} \ Or, any file created by a
process will be owned by the owner of the process.  The file will have
group ownership equal to the primary group owner of the process.  You
can check the ownership of the file using the \texttt{ls~-l} command.

\section{Procedure}
\label{sec:procedure}

\subsection{Exercises with the Set User ID Permission}
\label{sec:suid-exercises}

What we will do here is copy a shell program file to your
\texttt{/tmp} directory, execute it, and use the command
\texttt{whoami}, then exit, set the \SUID permission on the shell
executable file, run it again, and find out who you are.  Next, you
will change the ownership of the shell program, and run it again.  Do
this last step a number of times, until you see what is happening.
Don't forget to delete this shell file, as it is a great security
risk!

The \texttt{bash} shell has built in precautions against the danger of
running as a different user, but the simple shell \texttt{ash} does
not, so we will experiment with it.
\begin{enumerate}
\item Copy the \texttt{ash} shell to your \texttt{/tmp} directory (not
  your network directory, as only \emph{you} have permission to read
  that):
  \begin{alltt}
$ \textbf{sudo cp -a /bin/ash /tmp}
  \end{alltt}%$
  \begin{explanation}
    Copy the shell using \texttt{sudo} to preserve the ownership of
    the shell; it should be owned by the \texttt{root} user:
    \begin{alltt}
$ \textbf{ls -l /tmp/ash}
-rwxr-xr-x    1 root     root       110048 Jul 18 07:50 \ex{/tmp/ash}
    \end{alltt}%$
  \end{explanation}
\item Now execute it, and run the command \texttt{whoami}:
  \begin{alltt}
$ \textbf{/tmp/ash}
$ \textbf{whoami}
nicku
  \end{alltt}
  \begin{explanation}
    You may see some error messages saying ``\texttt{function: not
    found}''; this is because \texttt{ash} does not understand
    everything in your $\sim$\texttt{/.bashrc} login script.  Don't
    worry; this does not alter what we will learn here.
  \end{explanation}
\item Then exit:
  \begin{alltt}
$ \textbf{exit}
  \end{alltt}%$
\item and add the \SUID permission to the executable:
  \begin{alltt}
$ \textbf{sudo chmod u+s /tmp/ash}
\end{alltt}%$
\begin{explanation}
  We are adding the special permission to the \textbf{u}ser who owns
  the file (which is \texttt{root}).  The \texttt{chmod} (change mode)
  command changes the permissions on files.  Here, we \emph{add} the
  special permission to the existing permissions for the \textbf{u}ser
  who owns the file.
\end{explanation}
\item then list the permissions on the file:
  \begin{alltt}
$ \textbf{ls -l /tmp/ash}
-rwsr-xr-x    1 root     root       110048 Jul 18 07:50 \ex{/tmp/ash}
  \end{alltt}%$
  \begin{explanation}
    Notice that the only change from before is that the first
    ``\texttt{x}'' (for \textbf{u}ser) has changed into an
    ``\texttt{s}''.
  \end{explanation}

\item Now execute the shell and see who you are this time:
  \begin{alltt}
$ \textbf{/tmp/ash}
# \textbf{whoami}
  \end{alltt}%$
What user did you see?\answerbox{root}
\item Create a file in the \texttt{/tmp} directory:
  \begin{alltt}
# \textbf{touch /tmp/file}
# \textbf{ls -l /tmp/file}
  \end{alltt}
Which user owns the file?  Which group?\answerbox{root, your own group.}

\item Now change the ownership of the shell program to the user
  \textbf{apache}, run the shell, then see who you are:
  \begin{alltt}
# \textbf{exit}
$ \textbf{sudo chown apache /tmp/ash}
$ \textbf{ls -l /tmp/ash}
-rwsr-xr-x    1 apache   root       110048 Jul 18 07:50 \ex{/tmp/ash}
$ \textbf{/tmp/ash}
$ \textbf{whoami}
  \end{alltt}
What user did you see?\answerbox{root}
\item Open your file \texttt{/etc/passwd}, and select a number of
  other users.  Repeat the last exercise for each user.  Try creating
  files (perhaps with the \texttt{touch} command) and see who owns the
  files.  See which group owns each file.

\item Fill in the following table:\\[2ex]
  {\renewcommand{\extrarowheight}{1ex}
  \begin{tabularx}{\linewidth}{|c|c|Y|Y|Y|Y|Y|Y|}
    \hline%
    \emph{SUID?} & \emph{SGID?}
    & \emph{user that owns \textnormal{\texttt{/tmp/ash}}}
    & \emph{group that owns \textnormal{\texttt{/tmp/ash}}}
    & \emph{user that owns the process}
    & \emph{group that owns the process}
    & \emph{user that executes \textnormal{\texttt{/tmp/ash}}}
    & \emph{group that executes \textnormal{\texttt{/tmp/ash}}}\\
    \hline
    no & no & root & root & & & me & my group\\\hline
    yes & no & root & root & & & me & my group \\\hline
    yes & no & apache & root & & & me & my group \\\hline
    yes & no &  &  & & & me & my group \\\hline
  \end{tabularx}}\\[2ex]

\result[Conclusion]{3}{What general rule can you state about the
  effect of the \SUID permission?}{}
\end{enumerate}

\subsection{Exercises with Set Group ID Permission}
\label{sec:sgid-exercises}

Here you will do essentially the same exercise as before, but this
time with the \emph{set group \ID} (\SGID) permission turned on, and
the \SUID permission turned off.
\begin{enumerate}
\item Turn off the \SUID permission and turn on the SGID permission:
  \begin{alltt}
$ \textbf{sudo chmod u-s /tmp/ash}
$ \textbf{sudo chmod g+s /tmp/ash}
  \end{alltt}
  or, as one command,
  \begin{alltt}
$ \textbf{sudo chmod u-s,g+s /tmp/ash}
  \end{alltt}%$
  and list the file to ensure that the permissions are correctly set:
  \begin{alltt}
$ \textbf{ls -l /tmp/ash}
-rwxr-sr-x    1 apache   root       110048 Jul 18 07:50 \ex{/tmp/ash}
   \end{alltt}%$
   Note the ``\texttt{s}' is now in the permissions that apply to the
   \textbf{g}roup owner of the executable file.

 \item Now execute the shell, and see who you are:
   \begin{alltt}
$ \textbf{/tmp/ash}
$ \textbf{whoami}
   \end{alltt}
 \item Create a file, and list it to see who the user that owns the
 file is, and who the group that owns the file is:
 \begin{alltt}
$ \textbf{touch /tmp/newfile}
$ \textbf{ls -l /tmp/newfile}
 \end{alltt}
\item Exit from the shell, then change the group owner of the
  executable shell program file to a number of other users, perhaps
  yourself, the user \texttt{apache},\ldots
  \begin{alltt}
$ \textbf{sudo chgrp apache /tmp/ash}
$ \textbf{/tmp/ash}
$ \textbf{touch /tmp/newfile2}
$ \textbf{ls -l /tmp/newfile2}
  \end{alltt}%$
\item Fill in the following table:\\[2ex]
  {\renewcommand{\extrarowheight}{1ex}
  \begin{tabularx}{\linewidth}{|c|c|Y|Y|Y|Y|Y|Y|}
    \hline%$
    \emph{SUID?} & \emph{SGID?}
    & \emph{user that owns \textnormal{\texttt{/tmp/ash}}}
    & \emph{group that owns \textnormal{\texttt{/tmp/ash}}}
    & \emph{user that owns the process}
    & \emph{group that owns the process}
    & \emph{user that executes \textnormal{\texttt{/tmp/ash}}}
    & \emph{group that executes \textnormal{\texttt{/tmp/ash}}}\\
    \hline
    no & no & root & root & & & me & my group \\\hline
    no & yes & root & root & & & me & my group \\\hline
    no & yes & root & apache & & & me & my group \\\hline
    no & yes &  &  & & & me & my group \\\hline
    yes & yes &  &  & & & me & my group \\\hline
  \end{tabularx}}\\[2ex]

  \result[Conclusion]{3}{Explain what the effect of the \SGID permission is.}{}
  \result[Conclusion]{2}{How is the \SGID permission different from the \SUID
  permission on an executable file?}{}
\end{enumerate}


\subsection{Effect of Set Group ID Permission on a Directory}
\label{sec:sgid-on-directory}

The effect of the \SGID permission on a directory is that all files
created in the directory have a group owner equal to the group owner
of the directory.  This is very useful for group projects.  This is
discussed in detail in the module on user management in the workshop
notes.
\end{document}