Please mail me any problems with, or comments about this page.
PGP keys local copy
Homework must be submitted electronically to
<csci555@usc.edu>.
It should have a subject of “Homework
3.” You must submit plain text without
embedded formatting commands or markup (ASCII or UTF-8 are acceptable).
That means, among other things, no postscript, no Microsoft Word, no
PDF, no FrameMaker, no TeX, no groff, no DocBook, no HTML, no XML, and
no JavaDoc. Do not submit your homework as an attachment to your
e-mail. Do not base 64 encode it. Do not Rot13 encode it. Plain
text. You may PGP sign it, but are not required to do so. Do not PGP
encrypt it. If you submit something that is not unmarked-up text, it
is functionally the same as turning nothing in.
Homework turned in on the due date is not penalized, one day late is 25% off (that is the grade will be multiplied by 0.75), 2 days late is 50% off, and 3 days late is 75% off. No work will be accepted more than 3 days late. I will generally use the Date: line of the mail, but should the situation merit it, I am not above looking through mail system logs to confirm the submission time. I should not have to mention it, but forging a Date: line to avoid a late deduction is grounds for an F.
Do the work yourself. Computer science is a collaborative science, and I encourage you to talk over the ideas in the homework with other students. However, the final submission, that is, the text of the homework, must be composed individually by each student. If you hand in homework that is identical to another student, you risk failing the class. (In fact the only way that you would not fail the class in such a circumstance would be if one student had copied another student without the knowledge of the copied student; the copied student would not be penalized.) That is an awfully large risk for 10% of your total grade. Do the work yourself.
As with all work for csci555, this work is subject to the USC code of Student Conduct. Read it, learn it, live it. Should you have any questions on how to apply the code, do not hesitate to contact me or the Office of Student Judicial Affairs and Community Standards. Should it prove possible, do not plagiarize work from sources outside the class. Plagiarizing homework is grounds for failing the class. It is perfectly all right to properly cite external sources, should you find some that are useful.
Answers will not be graded on their beauty of expression. Answers will be graded on whether they show a logical approach and sensible explanation. Short, simple sentences are fine. What is important is that your ideas are clear to the reader, and that they answer the question. Of course, no answer will be penalized because it is beautifully expressed, either.
Each question has equal weight.
1. | Flask[Spencer99] describes a system where access control can be based on multiple facts about users and objects (e.g., files). For example, a file might be accessible to members of a given department and auditors, or to members of a department who are not supervisors. In most cases these kinds of permissions can be represented by traditional group-based file permissions, even if it is unwieldy. Explain how one can represent the example where all members of a department and auditors can read a given file. You can assume department members share a group and auditors do as well, and that you can create new groups. (3 points) Given that it is possible to represent those permissions, explain why label-based access control, like Flask, is better when complex permissions like the above are in use. Include an example to make your point. (7 points) |
Answer: |
To support that particular policy, you can just create
another group There are many problems with generalizing that approach to more cases. A system may run out of groups, or individual users may have upper bounds on the numbers of groups they can be in. Even if there is no upper bound on these things, group-based permissions are usually not coded using efficient algorithms for large numbers of members or groups.
Those objections can be addressed by better implementations
of the group system, but a more fundamental objection is
that the new groups represent the outcomes of analysis: a
user is in the
For example, if a user loses auditing permissions, they have
to be removed not only from the The label-based system reduces the number of things to get right - basic labels and one policy description - and the number of places it needs to be implemented correctly (the security manager). This makes for a simpler and more reliable system. |
Grading: | Three points for the example, and 7 for the discussion. The discussion must include an example and should state a specific case for using labels. |
2. | Many of the file system designs we discussed, including the Log-structured File system[Rosenblum91] and Soft-Updates[McKusick99] are based on using CPU and memory resources to compensate for the limitations of a storage system. What differences in file system design would you expect if the physical limitations on storage latency disappeared? Give a principle such a design would follow and a specific, practical difference in implementation. |
Answer: | Since current file systems trade CPU and memory to make larger asynchronous writes, if storage latencies went down, those trades would be wasted effort. A general goal a file system designer might pursue in that case is simplifying the file system operations to make better use of CPU and memory elsewhere in the system. Practically this might mean a simplification of the layout of the file system and a reduction in caching and organizing of synchronous and delayed writes. Rather than spending the overhead to track dependencies, for example, the writes would be made synchronously and in the proper order. |
Grading: | Five points for the general principle and 5 for a specific change. |
3. | Many papers we discussed this semester used microbenchmarks, which are simple performance evaluations, to assess the performance of their systems. Examples of microbenchmarks include the Create, Read, Write, Delete benchmarks in the LFS performance analysis paper[Seltzer95]. Explain why microbenchmark figures are not always accurate estimates of application performance. (5 points) How you think microbenchmarks should be used in assessing system performance? Support your position. (5 points) |
Answer: | Most application make use of many operating system services and different pieces of the hardware. Microbenchmarks, by definition exclude interactions between subsystems. As a result applications often see slower performance than microbenchmarks predict. Informed people have a range of opinions on how microbenchmarks can be applied, so this answer is graded based on how you support your position. Microbenchmarks form a basis for comparison between subsystems and an upper bound on overall system performance. It is extremely rare that application performance exceeds the predictions of the microbenchmarks. These two uses are valuable in that they allow simple subsystem comparisons and that they provide best case application limits. |
Grading: | 5 for explaining that applications use the whole system and 5 for a reasoned support for the microbenchmark position. |
4. | The microkernel implementations we discussed generally did not implement a unified access control system, and for those that did, there's no requirement that all servers use the same access control system. Explain one advantage and one disadvantage of that state of affairs. (5 points each) |
Answer: | One advantage is that a server that implements a new kind of object that implies a different access control model can implement that control within the server. For example, fine grained access control over each operation on services provided by a new piece of hardware can be provided without trying to wedge them into an access control system that does not support it. On the other hand, the prospect of multiple access control frameworks can confuse users and make certification or even understanding of the system's security policies impossible. A unified policy like flask's, or even the ability to audit a file system's permissions allows a security policy to be audited. If each component describes its own access controls, there is no unified vocabulary to look at. |
Grading: | Five for each of the advantage and disadvantage. The explanation is the bulk of the grade. |
[Spencer99] “The Flask Security Architecture: System Support for Diverse Security Policies,” The Eighth USENIX Security Symposium, USENIX, August 1999, 123-139,
[Rosenblum91] “The design and implementation of a log-structured file system,” 13th Symposium on Operating Systems Principles, ACM, October 1991, 1-15,
[McKusick99] “Soft Updates: A Technique for Eliminating Most Synchronous Writes in the Fast Filesystem,” FreeNIX Track: 1999 USENIX Annual Technical Conference, USENIX, June 1999, ,
[Seltzer95] “File System Logging Versus Clustering: A Performance Comparison,” USENIX Conference, January 1995, ,