April 3 through April 9

For Recitation, Thursday, April 3

Read Appendix 6.A from "The protection of information in computer systems" by Saltzer and Schroeder (pages 6-34 through 6-55 of reading #26). Pages 6-46 through 6-55 were missing from the reader, but we handed them out as handout #26. See the course secretary, Neena Lyall, in NE43-523 if you didn't get them.

Last year we asked the following question for a reading report. You do not have to answer this question, but thinking about this question might make the reading more exciting.

Look carefully at protection failure case studies #4 (the system programmer attack), #10 (the system release trick), and #12 (unintentional signaling with clandestine channels) of appendix 6.A. Choose one of these (or, choose an interesting protection failure you have encountered or read about on your own) and do one of the following:

1. Explain which, if any, of the security design principles described in "The protection of information in computer systems" (on pages 1282-3) were violated by the system in the case study.

2. Come up with a general security design principle of your own that, if applied, would have helped avoid that failure.

For Lecture, Monday, April 7

The last lecture on security. No specific reading assignment for today, but you might want to get going on the reading for tomorrow. Read parts B and C of Handout #24.

For Recitation, Tuesday, April 8

Each year we construct a handout on "Recent Issues Regarding Security and Privacy". This year's handout (Handout #24) is on issues in making it safe to execute applets. This handout will distribute in class on Wednesday April 2 (snow permitting). See the course secretary, Neena Lyall, in NE43-523 if you didn't get it.

Your reading report should answer the following question:

Consider two contrasting approaches to security mechanisms for mobile code (e.g., an applet): code signing (used by ActiveX) and sandboxing (used by Java). Does code signing actively prevent malicious mobile code from being executed? If not, why is code signing a useful security mechanism? In answering these two questions, it might be helpful to contrast the goals of code signing with sandboxing with regards to preventing malicious mobile code from being executed on a client's machine.

Sandboxing is discussed in section 6 of the Java White paper (Handout #24, Part C). It is not explicitly mentioned by name but the techniques in Section 6 combine to form a sandbox around the mobile code. Code signing is briefly talked about in the overview of Handout #24, part A and a bit more in Bob Atkinson's submission to comp.risks. It identifies the publisher of the code through a digital signature. Moreover, the signature is encoded with the code such that it also guarantees that the code has not been altered since it was signed.

For Lecture, Wednesday, April 9

Lecture on the management of storage systems. In preparation, read two things. First, read Tanenbaum chapter 5; skip section 5.2. Although the reading has a significant number of pages, it is pretty easy going. Second, read "The longevity of digital documents" by Rothenberg, reading #27. This paper is very light reading--just zip through it.


System aphorism of the week
The unavoidable price of reliability is simplicity. (C.A.R. Hoare)

6.033 Handout 23, issued 4/1/96