# HG changeset patch # User cu # Date 1509145041 -3600 # Node ID 86334134abe54882b4af59598d694719c5f02940 # Parent 192d01998ebd49de54a78cf8991a26694aeaadf2 updated cw diff -r 192d01998ebd -r 86334134abe5 coursework/cw01.pdf Binary file coursework/cw01.pdf has changed diff -r 192d01998ebd -r 86334134abe5 coursework/cw01.tex --- a/coursework/cw01.tex Mon Oct 23 21:00:14 2017 +0100 +++ b/coursework/cw01.tex Fri Oct 27 23:57:21 2017 +0100 @@ -6,25 +6,19 @@ \begin{document} \newcolumntype{C}[1]{>{\centering}m{#1}} -\section*{Coursework 7CCSMSEN} +\section*{Coursework for 7CCSMSEN} -This coursework is worth 4\% and is due on 19 October at -16:00. You are asked to implement a regular expression matcher -and submit a document containing the answers for the questions -below. You can do the implementation in any programming -language you like, but you need to submit the source code with -which you answered the questions, otherwise a mark of 0\% will -be awarded. You can submit your answers in a txt-file or pdf. -Code send as code. - +This coursework is worth 10\% and is due on 1 December at 16:00. You +are asked to fill in the access control matrix below giving the +correct access rights. You have to submit your answers at KEATS. You +can submit your answers in a txt-file or as pdf. \subsubsection*{Disclaimer} -It should be understood that the work you submit represents -your own effort. You have not copied from anyone else. An -exception is the Scala code I showed during the lectures or -uploaded to KEATS, which you can freely use.\bigskip +It should be understood that the work you submit represents your +\textbf{own} effort! You are not supposed to work in groups and have +not copied any solution from anyone else.\bigskip \subsection*{Task} @@ -34,40 +28,46 @@ \begin{center} \begin{verbatim} $ ls -ld . * */* -drwxr-xr-x 1 ping staff 32768 Apr 2 2010 . +drwxr-xr-x 1 ping staff 32768 Apr 2 2010 . -rw----r-- 1 ping students 31359 Jul 24 2011 manual.txt --r--rw--w- 1 bob students 4359 Jul 24 2011 report.txt --rwsr--r-x 1 bob students 141359 Jun 1 2013 microedit -dr--r-xr-x 1 bob staff 32768 Jul 23 2011 src --rw-r--r-- 1 bob staff 81359 Feb 28 2012 src/code.c +-r--rw--w- 1 bob students 4359 Jul 24 2011 report.txt +-rwsr--r-x 1 bob students 141359 Jun 1 2013 microedit +dr--r-xr-x 1 bob staff 32768 Jul 23 2011 src +-rw-r--r-- 1 bob staff 81359 Feb 28 2012 src/code.c -r--rw---- 1 emma students 959 Jan 23 2012 src/code.h \end{verbatim} \end{center} +\noindent with group memberships assigned as follows: \begin{center} \begin{tabular}{ll} -Members of group staff: & ping, bob, emma\\ -Members of group students: & emma\\ +Members of group staff: & \texttt{ping}, \texttt{bob}, \texttt{emma}\\ +Members of group students: & \texttt{emma}\\ \end{tabular} \end{center} -The file microedit is a text editor, which allows its users to open, edit and -save files. Note carefully that microedit has set its setuid flag. -Fill in the access control matrix below that shows for each of the above five files, -whether ping, bob, or emma are able to obtain the right to read (R) or replace (W) its +\noindent +The file \texttt{microedit} is a text editor, which allows its users +to open, edit and save files. Note carefully that microedit has set +its \textbf{setuid bit}. Fill in the access control matrix below +that shows for each of the above five files, whether \texttt{ping}, +\texttt{bob}, or \texttt{emma} are able to read (R) or replace (W) its contents using the editor microedit.\bigskip \begin{center} +\def\arraystretch{1.5} \begin{tabular}{r|c|c|c|c|c} & manual.txt & report.txt & microedit & src/code.c & src/code.h \\\hline ping & & & & &\\\hline bob & & & & &\\\hline emma & & & & &\\ \end{tabular} -\end{center} +\end{center}\bigskip - +\noindent +For help about how to fill in the access control matrix, see additional hints +uploaded to KEATS. \end{document} %%% Local Variables: diff -r 192d01998ebd -r 86334134abe5 coursework/so04.tex --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/coursework/so04.tex Fri Oct 27 23:57:21 2017 +0100 @@ -0,0 +1,365 @@ +\documentclass{article} +\usepackage{../style} +\usepackage{../langs} + +\begin{document} + +\section*{Hints for Coursework} + +\begin{flushright} +\it ``I have no special talents.\\ +I am only passionately curious.''\\ +\small--- Albert Einstein +\end{flushright}\medskip + +\noindent Many students seem to have some difficulties with this coursework. +While it can be solved with just logical +reasoning, this seems to me like learning swimming on dry land. +Why not trying out what an actual UNIX system has to say? +Seems obvious isn't it? ;o) + +\subsection*{Environment} + +I know at least three ways of how to set up a testing +environment without affecting my main computer, and which +should work regardless of whether you have a Windows, MacOSX +or Linux machine: + +\begin{enumerate} +\item You can download Oracle's VirtualBox + +\begin{center} +\url{https://www.virtualbox.org} +\end{center} + + There are binaries for Windows and MacOSX (I only tried + out MacOSX). In addition, you need to download a Linux + distribution. I used a recent iso-file of an Ubuntu + distribution. All components are free. + +\item If you happen to have a Raspberry Pi laying around (I + have two for playing music as well as for all sorts of + rainy-afternoon distractions). The cheapest model of a + Raspberry Pi costs around \pounds{7}. More expensive + versions cost around \pounds{20}. + You also need an + SD memory card of at least 4GB, which can be bought for + \pounds{5} or less. Some SD cards come pre-installed + with Linux, but all can be easily loaded with Linux. The + good thing about Raspberry Pi's is that despite their + miniature size and small cost, they are full-fledged + Linux computers\ldots{}exactly what is needed for such + experiments. There are plenty Linux distributions on the + Net that are tailored to work ``out of the box'' with + Raspberry Pi's. + +\item If you have a spare memory stick laying + around, you can try out any of the live USB-versions + of Linux. + + \begin{center} + \url{https://en.wikipedia.org/wiki/Live_USB} + \end{center} + + The idea is to upload Linux on the USB stick, you plug + it into your computer and boot up a Linux system without + having to download anything to your computer. A notable + live USB version of Linux is called Tails + + \begin{center} + \url{https://tails.boum.org} + \end{center} + + which comes with Tor pre-installed and is for people who + need a maximum of privacy and anonymity (whistleblowers, + dissidents). It is being said that journalists Laura + Poitras and Glenn Greenwald used it when talking to + Edward Snowden. Tails gives them anonymity even if their + main system is compromised by malicious software, for + example installed by the NSA. + + However, a live USB Linux will need some support from + the computer (BIOS) where you plug in the USB stick. I + know Apple computers are a bit ``special'' with this and + would need a 3rd-party boot loader for loading operating + systems from an USB memory stick. + + An alternative is to burn a CD/DVD with a live Linux + distribution. But perhaps CDs/DVDs are already obsolete + technology not available to everyone. The point is that + loading an operating system from such a media is/was + much better supported by various computers. + +\end{enumerate} + +\noindent For my experiments below, I used option 2. In +earlier versions of this module I have used option 1. I have +not tried in a while option 3, but know that in the past I had +a dedicated bootloader on an Apple computer just for the +purpose of running operating systems from external disks. I +also for a long time had spare CDs laying around just for the +purpose that my (Linux) operating system got trashed enough so +that it had to be rebooted externally. + +\subsection*{Setup} + +Once you have Linux up and running, there are a few commands +you need to know in order to replicate the ownerships and +permissions from the question: + +\begin{itemize} +\item \texttt{useradd} creates a new user +\item \texttt{groupadd} creates a new group +\item \texttt{adduser} adds a user to a group +\item \texttt{chmod} changes the permissions of a file +\item \texttt{chown}, \texttt{chgrp} change the ownership and +group of a file +\end{itemize} + +\noindent There is also a choice to be made what to use as +microedit. If you do not want to make your hands dirty and +write a test program yourself, I recommended to use the +editors \texttt{vi} or \texttt{vim}, which is available on +pretty much every UNIX system. For a first try out, this is a +helpful choice for solving the question. However, it has a +disadvantage: it will always assume you have read permissions +to a file. To use these editors, I made a copy of them +and renamed them to \texttt{microedit}. Be careful to set the +setuid bit for \texttt{microedit}. + + +\subsection*{Permission Basics} + +The absolute basics is how the permissions are organised +in essentially four blocks + +\begin{center} +${\underbrace{\huge\texttt{-}}_{\text{\makebox[0mm]{directory}}}} + {\underbrace{\huge\texttt{-{}-{}-}}_{\text{user}}}\, + {\underbrace{\huge\texttt{-{}-{}-}}_{\text{group}}}\, + {\underbrace{\huge\texttt{-{}-{}-}}_{\text{other}}}$ +\end{center} + +\noindent This seems to be the knowledge everybody has. But +already difficulties arise with the following fact, which +could easily be resolved by a little experiment: assume a file +is owned by Bob with permissions + +\begin{center} +$\texttt{-{}r-{}-{}rw-{}rwx\;\;bob\;students\;\;file\_name}$ +\end{center} + +\noindent The UNIX access rules imply that Bob will only have +read access to this file, even if he is in the group students +and the group access permissions allow read and write. +Similarly every member in the students group who is not Bob, +will only have read-write access permissions, not +read-write-execute. + +The question asked whether Ping, Bob and Emma can read or write +the given files \underline{\smash{using}} the program +microedit. This means we will call on the command line + +\begin{center} +$\texttt{>}\;\;\texttt{microedit}\;\textit{file\_name}$ +\end{center} + +\noindent for all files and for Bob, Ping and Emma. So if you +want to find out whether Bob, say, can read or write a file, +you need to find out what the access permissions with which +\texttt{microedit} is run. This would be easy, if +\texttt{microedit} did not have the setuid bit set. Then it +would be just the rights of the caller (Ping, Bob or Emma). +But your friendly lecturer arranged the question so that it +has the setuid bit. + +Recall that the setuid bit gives the program the ability to +run with the permissions of the owner \texttt{microedit} +file, not the permissions of the caller. I wrote in the +handout + +\begin{quote}\it +``The fundamental idea behind the setuid attribute is that a +file will be able to run not with the callers access rights, +but with the rights of the owner of the file.'' +\end{quote} + +\noindent Something similar is written in the Wikipedia +entry for setuid + +\begin{center} +\url{http://en.wikipedia.org/wiki/Setuid} +\end{center} + +\noindent This implies for deciding whether \textit{file} is +readable or writable is not determined by the caller, but by +the permissions with which \texttt{microedit} runs. As you +might know already, and can also see in the Figure~\ref{test} +shown later, any \textit{file\_name} given on the command line +will be handed over to microedit as string. It is the +``responsibility'' of \texttt{microedit} what to do with it. + + +There is one caveat however: We need to find out first whether +the caller (Bob, Ping or Emma) can actually run +\texttt{microedit}---that is has execute permissions for +\texttt{microedit}. Once \texttt{microedit} runs, it will +assume the permissions of the owner of \texttt{microedit}. The +question is now whether these permissions are sufficient to +read or write the file \textit{file\_name}. The hints so far +should already be useful for answering the first three +columns. + +For the other two files we have to take into account that they +are inside a directory. For directories apply special access +rules. In the handout I wrote + +\begin{quote}\it +``There are already some special rules for directories and +links. If the execute attribute of a directory is \emph{not} +set, then one cannot change into the directory and one cannot +access any file inside it. If the write attribute is +\emph{not} set, then one can change existing files (provide +they are changeable), but one cannot create new files. If the +read attribute is \emph{not} set, one cannot search inside the +directory (\texttt{ls -la} does not work) but one can access an +existing file, provided one knows its name.'' +\end{quote} + +\noindent With this also the last two columns can be filled +in. + +% \subsection*{Advanced Permissions} + +% While all hints so far should get you very close to the +% intended answers, there is one further complication arising +% from the setuid bit. The question asked: + +% \begin{quote}\it +% \ldots{}whether Ping, Bob, or Emma \underline{are able} to obtain +% the right to read (R) or replace (W) its contents using +% the editor microedit. +% \end{quote} + +% \noindent Note the underlined phrase. That means we need to +% ensure that there is no other way for Bob, Ping and Emma to +% obtain reading or writing permissions with \texttt{microedit}. +% Actually there is. Any file that has the setuid bit set will +% be called with the permissions of the owner, but once it has done +% the work, it can ``lower'' the permissions again to the +% callers rights. This is a second possibility we have to check +% whether the files become readable or writable when the +% permissions of the caller are re-instated. In the handout +% I wrote about the setuid-program \texttt{passwd}: + +% \begin{quote}\it +% ``As an example consider again the \texttt{passwd} +% program. When started by, say the user \texttt{foo}, it has at +% the beginning the identities: + +% \begin{itemize} +% \item \emph{real identity}: \texttt{foo}\\ +% \emph{effective identity}: \texttt{foo}\\ +% \emph{saved identity}: \texttt{root} +% \end{itemize} + +% \noindent It is then allowed to change the effective +% identity to the saved identity to have + +% \begin{itemize} +% \item \emph{real identity}: \texttt{foo}\\ +% \emph{effective identity}: \texttt{root}\\ +% \emph{saved identity}: \texttt{root} +% \end{itemize} + +% \noindent It can now read and write the file +% \texttt{/etc/passwd}. After finishing the job it is supposed to +% drop the effective identity back to \texttt{foo}. This is the +% responsibility of the programmers who wrote \texttt{passwd}. +% Notice that the effective identity is not automatically +% elevated to \texttt{root}, but the program itself must make +% this change. After it has done the work, the effective +% identity should go back to the real identity. +% '' +% \end{quote} + +% \noindent It was hoped by your friendly lecturer that any of +% the students would have consciously considered this +% possibility, but alas nobody did\ldots{} + +\subsection*{A Program in C} + +I suggested above to use a copy of the editors \texttt{vm} or +\texttt{vim} for \texttt{microedit}. This works reasonably +well, except for one instance: if a file is not readable, then +these editors will not be helpful for checking whether the +file is writable. Giving out such a permission is a perfectly +``normal'' situation in many large UNIX systems. A user might +be allowed to write into central log files, but should not be +able to read them (otherwise they can find out what other +users did). To get around this problem, I brushed up my C +knowledge from school days and googled around for how to read +and write files. Typing in ``read write in C'' in the +all-knowing search engine, I obtained the link + +\begin{center} +\url{https://www.cs.bu.edu/teaching/c/file-io/intro/} +\end{center} + +\noindent which tells you pretty much everything what there is +about opening a file in C for reading and writing. (There are +certainly more and better sources for finding out how to read +and write files. This was just at my finger tips.) A little +bit more googling helped me to display the user that +determines the access permissions. Being lazy, I did not spend +a thought of refactoring the file to be as small as possible, +and also did not go the extra mile to convert the ID of the +user into a clear name. + +The resulting little C program is shown in Figure~\ref{test}. +It explicitly checks for readability and writability of files. +The \pcode{main} function is organised into two parts: the +first checks readability and writability with the permissions +according to a potential setuid bit, and the second (starting +in Line 34) when the permissions are lowered to the caller. +Note that this program has one problem as well: it only gives +a reliable answer in cases a file is {\bf not} readable or +{\bf not} writable. In these cases it returns an error code 13 +(permission denied). It sometimes claims a file is not +writable, say, but with an error code 26 (text file busy). +This is unrelated to the permissions of the file. + +\begin{figure}[t] +\small\mbox{}\\[-14mm] +\lstinputlisting[language=C]{../progs/read.c}\mbox{}\\[-13mm] +\caption{A read/write test program in C. It returns errno = 13 +in cases when permission is denied.\label{test}} +\end{figure} + +%\subsection*{Solution} +% +%\begin{center} +%\begin{tabular}{r|c|c|c|c|c} +% & manual.txt & report.txt & microedit & src/code.c & src/code.h \\\hline +%ping & R- & R- & RW & -- & --\\\hline +%bob & R- & R- & RW & -- & --\\\hline +%emma & -- & -- & -- & -- & --\\ +%\end{tabular} +%\end{center} +% +%\begin{center} +%\begin{tabular}{r|c|c|c|c|c} +% & manual.txt & report.txt & microedit & src/code.c & src/code.h \\\hline +%ping & RW & -W & RW & R- & --\\\hline +%bob & R- & R- & RW & -- & --\\\hline +%emma & -- & -- & -- & -- & --\\ +%\end{tabular} +%\end{center} + + +\end{document} + +%%% Local Variables: +%%% mode: latex +%%% TeX-master: t +%%% End: