8 \section*{Handout 4 (Unix-Style Access Control)}

     9 \section*{Handout 4 (Access Control)}

    11 access to a resource or deny it. This sounds easy. Right? Well

    12 access to a resource or deny it. Sounds easy. No? Well it

    12 it turns out that things are not as simple as seem at first.

    13 turns out that things are not as simple as they seem at first

    13 Let us study as a case how access is organised in Unix-like

    14 glance. Let us first look as a case-study at how access

    14 systems (Windows systems have generally similar access

    15 control is organised in Unix-like systems (Windows systems

    15 control, although the details might be quite different).

    16 have similar access controls, although the details might be

    16  

    17 quite different).

    18 

    19 

    20 \subsubsection*{Unix-Style Access Control}

    21 

    18 a file, even memory or ports, access control is organised

    23 a file, even memory, ports and so on, access control in Unix

    19 around 11 Bits that specify how a file can be accessed. There

    24 is organised around 11 Bits that specify how a file can be

    20 are three modes for access \textbf{r}ead, \textbf{w}rite and

    25 accessed. These Bits are sometimes called the \emph{permission

    21 e\textbf{x}ecute. Moreover there are .... owner, group and

    26 attributes} of a file. There are typically three modes for

    22 everybody else.

    27 access: \textbf{r}ead, \textbf{w}rite and e\textbf{x}ecute.

    28 Moreover there are three user groups to which the modes apply:

    29 the owner of the file, the group the file is associated with

    30 and everybody else. A typical example of some files with

    31 permission attributes is as follows:

    32 

    33 {\small\lstinputlisting[language={}]{../slides/lst}}

    34 

    35 \noindent The leading \pcode{d} in Lines 2 and 6 indicate that

    36 the file is a directory, whereby in the Unix-tradition the

    37 \pcode{.} points to the directory itself. The \pcode{..}

    38 points at the directory ``above'', or parent directory. The

    39 second to fourth letter specify how the owner of the file can

    40 access the file. For example Line 3 states that \pcode{ping}

    41 can read and write the \pcode{manual.txt}, but cannot execute

    42 it. The next three letters specify how the group members of

    43 the file can access the file. In Line 4, for example, all

    44 students can read and write the file \pcode{report.txt}.

    45 Finally the last three letters specify how everybody else can

    46 access a file. This should all be relatively familiar and

    47 straightforward. No?

    48 

    49 There are already some special rules for directories. If the

    50 execute attribute of a directory is \emph{not} set, then one

    51 cannot change into the directory and one cannot access any

    52 file inside it. If the write attribute is not set, then one

    53 can change existing files (provide they are changeable), but

    54 one cannot create new files. If the read attribute is not set,

    55 one cannot search inside the directory (\pcode{ls -la} does

    56 not work) but one can access an existing file, provided one

    57 knows its name.

    58 

    59 While the above might sound moderately complicated, the real

    60 complications with Unix-style file permissions involve the

    61 setuid and setgid attributes. For example the file

    62 \pcode{microedit} in Line 5 has the setuid attribute set

    63 (indicated by the \pcode{s} in place of the usual \pcode{x}).

    64 The purpose of setuid and setgid is to solve the following

    65 puzzle: The program \pcode{passwd} allows users to change

    66 their passwords. Therefore \pcode{passwd} needs to have write

    67 access to the file \pcode{/etc/passwd}. But this file cannot

    68 be writable for every user, otherwise anyone can set anyone

    69 else's password. So changing securely passwords cannot be

    70 achieved with the simple Unix access rights discussed so far.

    71 While this situation might look like an anomaly, it is in fact

    72 an often occurring problem. For example looking at current

    73 active processes with \pcode{/bin/ps} requires access to

    74 internal data structures of the operating system. In fact any

    75 of the following actions cannot be configured for single

    76 users, but need privileged root access

    77 

    78 \begin{itemize}

    79 \item changing system databases (users, groups, routing tables

    80 and so on)

    81 \item opening a network port below 1024

    82 \item interacting with peripheral hardware, such as printers, 

    83 harddisk etc

    84 \item overwriting operating system facilities, like

    85 process scheduling and memory management

    86 \end{itemize}

    87 

    88 \noindent This will typically involve quite a lot of

    89 programs on a Unix system. I counted 87 programs with the

    90 setuid attribute set on my bog-standard MacOSX system

    91 (including the program \pcode{/usr/bin/login}).

    92 The problem is that if there is a security problem with

    93 one of them, then malicious users (or outside attackers)

    94 can gain root access.

    95 

    96 \subsubsection*{Secrecy and Integrity}