Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!think.com!sdd.hp.com!uakari.primate.wisc.edu!zaphod.mps.ohio-state.edu!wuarchive!decwrl!mcnc!uvaarpa!murdoch!fermi.clas.Virginia.EDU!gl8f
From: gl8f@fermi.clas.Virginia.EDU (Greg B. Lindahl)
Newsgroups: comp.os.misc
Subject: a question about Multics
Keywords: multics
Message-ID: <1991Jan10.185854.3071@murdoch.acc.Virginia.EDU>
Date: 10 Jan 91 18:58:54 GMT
Sender: news@murdoch.acc.Virginia.EDU
Organization: Department of Astronomy, University of Virginia
Lines: 30

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?