gl8f@fermi.clas.Virginia.EDU (Greg B. Lindahl) (01/11/91)
After reading Organick's Multics book, I have a question about one of the security examples. On page 141-142 an example is given of an automatic grading scheme. The teacher creates a directory into which students can copy their program segments, each with a unique entry point <sub_stu_id>. Then, after the deadline for turning in the assignment, the teacher creates an ACL entry for each student segment to run in a less-privledged ring than the teacher's grading program. Then the grading program calls each student routine one-by-one, and the student routine allegedly can't cheat. However, from my limited understanding of Multics, there are quite a few ways for the student to cheat, mainly because the teacher will be executing the student subroutine with the teacher's userid. 1. The student program could call another segment elsewhere to perform the actual work, allowing him to do the work after the deadline. 2. The student program could call another student program to do the work. This is the more interesting option ;-) I am also not sure, from the ACL description, whether or not the student segment when running as the teacher would be able to change the ring-33 ACL to allow write privilege, which would allow the student segment to randomly destroy other student's work. I'd guess that it's illegal for a ring-33 procedure to change an ACL created by a ring-32 procedure. Do I have this right? Wrong? Comments?
barmar@think.com (Barry Margolin) (01/11/91)
In article <1991Jan10.185854.3071@murdoch.acc.Virginia.EDU> gl8f@fermi.clas.Virginia.EDU (Greg B. Lindahl) writes: >After reading Organick's Multics book, I have a question about one of >the security examples. Disclaimer: It's been a while since I've read Organick, and it's at home somewhere so I can't look at the example you cite while answering. >On page 141-142 an example is given of an automatic grading scheme. >The teacher creates a directory into which students can copy their >program segments, each with a unique entry point <sub_stu_id>. Then, >after the deadline for turning in the assignment, the teacher creates >an ACL entry for each student segment to run in a less-privledged ring >than the teacher's grading program. Then the grading program calls >each student routine one-by-one, and the student routine allegedly >can't cheat. I'm guessing that it was specifically trying to prevent the type of cheating where the program alters the grading database. Also, I think this example uses a Multics feature that was never fully implemented: call-out. Multics allows calling more-privileged rings via gates, and they can return to the less privileged ring. But calling less-privileged rings doesn't really work. I think the problem was with initializing various parts of the environment (in the case of returning, this isn't a problem because the environment must have been initialized before the call). The only part of Multics that depends on transfering from an inner ring to an outer ring is process creation, and it uses special code that initializes the initial outer ring, and then fakes a return from a gate. I think there's also a security problem if you allow an outer ring to return to the inner ring, because the outer ring procedure could alter the return address in its stack and effectively transfer anywhere in an inner ring. However, I don't think this problem destroys the example. The teacher could login to the outer ring in order to run the students' programs, rather than calling them from the inner ring. >However, from my limited understanding of Multics, there are quite a >few ways for the student to cheat, mainly because the teacher will be >executing the student subroutine with the teacher's userid. > >1. The student program could call another segment elsewhere to perform > the actual work, allowing him to do the work after the deadline. I think this is correct. >2. The student program could call another student program to do the > work. This is the more interesting option ;-) Before running a student A's program, the teacher could change the access on the other students' directories and programs so that A doesn't have access to them. Just changing them all to the inner ring would be good enough, as you were correct in guessing that a ring-N process can't modify the access on a ring-<N-1> object (by the way, Multics was only implemented with 8 rings, and rings 6 and 7 were hardly ever used (they don't have direct access to the standard system call gates; there was once a design for a Unix emulator that put the Unix kernel in ring 3 (4 is the normal user ring) and Unix user mode in ring 6, with system calls being gates from 6 to 3), so few people are bothered that the original 64-ring design was abandoned). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
kittlitz@granite.cr.bull.com (Edward N. Kittlitz) (01/11/91)
In article <1991Jan10.211253.24868@Think.COM> barmar@think.com (Barry Margolin) writes: >Also, I think this example uses a Multics feature that was never fully >implemented: call-out. Typing as someone who successfully implemented a Multics subsystem which used call-out (more privileged, but not actually supervisor ring invoking a program in a less-privileged ring), I must disagree. The Batch Job Processor (BJP) consisted of ring4 code which obtained "jobs" from a card reader. Each job consisted of a language directive (C, Fortran), source code, and optional data. If I tell you that there were two card readers, you will realize that I am not joking. All first-year students used cards, as terminals were scarce. The goal (met) of BJP was to increase the throughput of these jobs by eliminating the standard overhead of creating a process for each one. I recollect process creation overhead as being a significant fraction of a second, while the actual compile/execute time was often less than that. I can't remember whether I did the compilation in ring4 or ring5. (Compilers being relative well-behaved, I might have "trusted" them.) At any rate, there was a timer set for each job. The program was actually executed in ring5. If the program was well-behaved, it returned to its ring5 caller (the equivalent of crt0), which returned to ring4 using a gate. The ring5 environment was re-initialized (all newly created static tossed out, etc), in preparation for the next job, and the output file was queued for printing. It's been over 10 years, but I was able to cope with common errors such as an invalid address (null pointer reference) or excessive CPU consumption. I may have had to use Multics "static condition handlers" to ensure that ring4 got control of a signal caused by ring5. (Greg B. Lindahl) writes: >>1. The student program could call another segment elsewhere to perform >> the actual work, allowing him to do the work after the deadline. >>2. The student program could call another student program to do the >> work. This is the more interesting option ;-) I believe it is possible to prevent access to other segments, but it may require substantial effort. You would then also need to supply your own ring5 version of system call gates, such as hcs_. The gate would transfer to ring4, and permitted calls would be reissued to the real hcs_. e.g. initate-segment and change-search-rules would be constrained. The teacher must also determine that the program is doing real work, and not (for example), simply writing out some correct answers. ----- E. N. Kittlitz kittlitz@world.std.com / kittlitz@granite.cr.bull.com Contracting at Bull, but not alleging any representation of their philosophy. -- ----- E. N. Kittlitz kittlitz@world.std.com / kittlitz@granite.cr.bull.com Contracting at Bull, but not alleging any representation of their philosophy.