Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!usc!samsung!think.com!barmar From: barmar@think.com (Barry Margolin) Newsgroups: comp.os.misc Subject: Re: a question about Multics Keywords: multics Message-ID: <1991Jan10.211253.24868@Think.COM> Date: 10 Jan 91 21:12:53 GMT References: <1991Jan10.185854.3071@murdoch.acc.Virginia.EDU> Sender: news@Think.COM Organization: Thinking Machines Corporation, Cambridge MA, USA Lines: 65 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 . 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- 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