Lab 3-Privilege Separation

Lab 3: Privilege Separation

back to Home

Lab Overview

In this lab, you’ll explore privilege separation. The key insight of privilege separation is

to give minimal privilege to each component of a system, so that when one component

of the system is comprised, other components will not be comprised too.

To make the discussion concrete, you will do this lab for the Touchstone web server,

that is, you will privilege-separate the Touchstone web server by giving each component

appropriate privilege. To be specific, you will first examine possible bugs in the source

2, the current one is based on the idea of services;

Part B: you will explore jail, by which you can constraint the service in some fake

root directory; and

Part C: you will privilege-separate the Touchstone web server by assigning each

component appropriate privilege.

Lab Environment

Download lab 3 code to start with. In order to bind to the port 80 (the default HTTP

port), you will start the touchstone web server with the root privilege in this lab (in

Linux, only root-privilege process can bind to port less than 1024):

which will make your exploitations easier. However, keep in kind that it’s also possible

to compromise the application when ASLR and other protections are on, just as you did

in lab 2.

Part A: The Touchstone Web Server

To help you finish this lab, let’s first examine the architecture and source code of the

Touchstone web server, which differs from the ones that you’ve seen in previous labs.

The overall design and architecture of the Touchstone web server is described in the

following figure. The server consists of three main components: the server (server), the

HTTP request dispatcher (httpd), and one or more services (Filesv, Banksv, etc..).

The server launches the HTTP dispatcher httpd, and two services: the filesv and the

dynamic bank services, which models a typical web-based electronic bank. Nevertheless

to say, a production web server will likely to contain more kinds of services.

Next, the dispatcher will route the requests to the corresponding service. The service

continues to read the HTTP headers and the body (if any), and respond appropriately.

Now, the Touchstone is up.

The main design consideration for the current architecture is to simplify design and to

increase throughout. By routing different request into different service, each service

can be kept as simple as possible and be implemented without too much difficulty. By

using a multi-process architecture, requests can be processed concurrently and high

throughout can be achieved (hopefully).

Exercise 1.