DOC PREVIEW
Stanford CS 155 - Study Notes

This preview shows page 1-2 out of 6 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 6 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

CS155: Computer Security Spring 2002Project #2Due: Monday, May 27th, 2002.Summary In this project, you will write Josh, the journaling operator shell. Josh is asetuid-root shell that allows users to undertake a subset of root’s capabilities.Your starting point is OSH, a minimal shell developed by Gunnar Ritter.You may work alone, or in pairs. You should not collaborate with others outside yourgroup.You will use the Boxes system again. Remember to test your Josh in a closedbox.The Problem As discussed in class, the classical Unix permissions model does not manageprivilege delegation effectively. To perform routine administrative tasks (such as clean-ing out the /tmp directory), one must possess the root password, and can thereforeperform other, undesirable actions (such as reading users’ mail).This limitation manifests itself most acutely in large Unix installations, where thereare typically many administrators tasked with various duties.Various systems have been devised to overcome this limitation, and allow unprivilegedusers to undertake some subset of root’s capabilities. A commonly-used example issudo (http://www.sudo.ws/).We will take an approach more like that taken by OSH, the Operator Shell (http://www.engarde.com/~mcn/osh.html). You might want to read the SANS III conferencepaper linked from the OSH home page.Our Solution We will develop a new shell, called Josh — the Journaling operator shell —which will enable privilege delegation in the Unix environment.In Unix, the command interpreter is not part of the kernel, and is in fact modularand interchangeable. The command interpreter program is called a shell; it reads userrequests, parses them, and makes the system calls required to fulfill the requests onthe user’s behalf. Seventh Edition Unix (Jan 1979) shipped with the Bourne Shell,/bin/sh; 2BSD (May 1979) shipped with Bill Joy’s C Shell (/bin/csh). The KornShell(/bin/ksh) was first released in 1983 and was for some time an at-cost addon for UnixSystem V.Today, people typically use either bash, a Bourne-shell reimplementation, or tcsh, a CShell enhancement.None of these shells is designed to be run setuid-root.1Starter Code Writing a shell is an excellent example of a Simple Matter of Programming(http://tuxedo.org/jargon/html/entry/SMOP.html). Besides the fork-exec-open-pipe infrastructure required for implementing shell pipelines, there’s a considerableamount of parsing and bookkeeping that must be taken care of.To keep you from having to start your project by implementing a shell — an excel-lent CS193u project, by the way — we provide you with OSH, the Old Shell (no re-lation to the Operator Shell). OSH is a feature-for-feature-compatible reimplementa-tion of the Sixth Edition shell (May 1976) by Gunnar Ritter (http://omnibus.ruf.uni-freiburg.de/~gritter).While OSH lacks some features we expect in modern shells (notably backticks andcontrol structures) it packs quite a few features into 837 lines of C. (Bash is about100,000 lines.)Recommended Reading For some practical ideas about security dos and don’ts, readDavid Wheeler’s “Secure Programming for Unix and Linux HOWTO” (http://www.dwheeler.com/secure-programs/), which is linked from the course website.For Unix programming in general, there is no better source than W. Richard Stevens’“Advanced Programming in the UNIX Environment” (Addison-Wesley, 1992, ISBN0-201-56317-7). Go buy it now.You might also want to refer to the source of various software components with whichJosh will interact, such as the Linux kernel (http://www.kernel.org/) or the GNUC Library (http://www.gnu.org/software/libc/).Using Boxes The Boxes distribution has been upgraded to the latest User-Mode Linuxpatch. This patch should hopefully address some of the instability that was encounteredduring the first programming project.The filesystem image has been upgraded to the latest from Debian. We have addedthe Expect utility (http://expect.nist.gov/), to allow you to test your shell outnon-interactively, if you wish.The wrapper interface to Boxes remains the same. You should check out the FAQposted to the newsgroup for basic information on getting Boxes up and running.Step One: Secure the Perimiter Now we describe the tasks you must undertake in cre-ating Josh. Of course, you need not stick to the order in which we present them.Though OSH, your starter shell, is good code, it was not written to be run setuid root.You should start by familiarizing yourself with the structure of the shell, auditing itwith security in mind, and thinking about how best to extend it.Step Two: Executables Josh allows users to run some programs that otherwise they couldnot. The file that controls this behavior is /etc/josh exec. This file (which shouldbe installed root:root, mode 600) has entries, one per line, in the following format:userid:progpath2(Without the initial indentation.) Here, userid is a user’s login name; progpath issome absolute path to a program. Any program listed in josh exec for a particularuser should be executed as root, not as the user, whenever it is invoked. For example,if /etc/josh exec includes the linealice:/bin/killThen any kill invoked by alice should run as root.Note that your Josh will have to figure out which program is actually invoked when auser types a non-absolute file name, or relies on the value of $PATH to find the program.Your Josh should ignore any entries in josh exec that do not name executable pro-grams.Step Three: File Access An administrator will need to read some files that are not read-able by all users, and possibly to write to other files that are not writable by all users.Josh will open these files on behalf of the administrator.Josh decides whether to open these files based on a configuration file, /etc/josh access.This file (which should be installed root:root, mode 600) has entries, one per line, infollowing format:userid:filepath:permsHere, userid is a user’s login name; filepath is some absolute file name; and permsis of the form [+-](r|w|rw). A + grants a positive right; a - takes away a previouslygranted right. For example, the entryalice:/etc/motd:+wMeans that Alice is allowed to write to the file /etc/motd. (Read access need not begranted, because everyone can read /etc/motd by default.)Entries are cumulative. Thus the two linesbob:/etc/ssh/ssh_host_key:+rbob:/etc/ssh/ssh_host_key:+wTogether mean that Bob can both read and write to the ssh host key file.Negative rights are only


View Full Document

Stanford CS 155 - Study Notes

Documents in this Course
Lecture 5

Lecture 5

64 pages

Phishing

Phishing

31 pages

Load more
Download Study Notes
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Study Notes and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Study Notes 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?