From: Justin Voskuhl (justinv_at_microsoft.com)
Date: Wed Jan 07 2004 - 16:57:21 PST
In Protection and the Control of Information Sharing in Multics Saltzer
describes the access control model they've implemented in Multics. He
describes many of the security tenets that he used in the design of the
model that we take for granted today, like the principle of least
privilege and defense-in-depth. He explains which objects in the system
are access controlled (many, down to even blocks of memory gets access
controls) and explains what the ACL model in Multics looks like. The
ACL system has a nice feature in that users can include project-related
settings on their ACEs which let them designate what they're doing with
a system by project, for instance today I'm sitting down to work on
project A, so that might be assigned a project name. Processes that run
while I'm working on this project can't access files marked for project
B, which prevents me from accidentally blowing away files unrelated to
A. This seems like a good idea but I wonder in practice if people found
it too cumbersome.
Another interesting aspect of the system was how the access controls on
memory segments handled which function entry points you could call
within the system via objects called "gates."
Another idea I liked was the idea of the "trap procedure" whereby if I
wanted to protect an object within the system, I could specify a
function to call which would determine if access is permitted. The idea
was abandoned but it seems like if you could restrict what one could do
in the function you might be able to make the problem tractable.
Many of the security problems with Multics are ones we face today still.
People pick weak passwords. UI for settings ACLs is hard to understand
for most people. Some sensitive messages in the system are transferred
over non-encrypted links (think non SSH telnet.) Disk storage isn't
wiped clean, so users may be able to see "old" data there. The operator
accounts are too all-powerful. (Windows NT has this problem today.)
This archive was generated by hypermail 2.1.6 : Wed Jan 07 2004 - 16:57:22 PST