From: Chuck Reeves (creeves_at_windows.microsoft.com)
Date: Wed Jan 07 2004 - 13:43:18 PST
The paper describes the design and tradeoffs of the security features of
an operating system called Multics. Designed at MIT around 1967, the
system was committed to a number of principles surrounding the
protecting access to information. These included: secure by default, no
security through obscurity and the principle of least privilege. These
ideas have been part of the foundation that myself and other engineers
at MS have only recently have been forced to embrace. The discussion of
the system's use of access control lists (ACL's) to secure information
and objects rang familiar. It was interesting to see that even back then
sequencing of access control entries (ACE's) in ACL's was already a real
problem. This is unfortunately still true for MS developers today. I
found the information on the "trap" extension, (an extensible facility
for programmatic authorization) to be quite interesting I would be
interested in discussing about how this work has evolved (if at all).
The benefits of centralized versus distributed management of access
control lists struck me as a complex problem requiring a more flexible
solution than presented here. The idea of delivering monthly audit
reports of login activity to users seemed like a simple but useful idea.
I found the section on memory protection and security descriptors the
most difficult to get through. I can see how enforcing access control at
the hardware level makes sense. Are there really any alternatives? In
the weaknesses section the author seemed to indicate that this system
still suffers from some of the very things he was trying to avoid.
Including, too much code running with elevated privileges (inside the
supervisor) and poor validation of input. These are the same sort of
things that have led Windows to be susceptible to a large number of
buffer overrun attacks.
This archive was generated by hypermail 2.1.6 : Wed Jan 07 2004 - 13:43:32 PST