From: Raz Mathias (razvanma_at_exchange.microsoft.com)
Date: Thu Jan 08 2004 - 17:35:37 PST
This paper begins by presenting what are even today the most relevant
design principles in protection. Having recently read Writing Secure
Code, by Michael Howard, it is interesting to note how many ideas from
30 years ago are being reintroduced. Ideas such as design is not a
secret ("Obscurity is not security" in Howard's book), principle of
least privilege, and default situation is lack of access are ideas being
hyped as new and exciting in mainstream server and operating system
design. In several ways, though, the paper does go in the wrong
direction (e.g. "password of up to eight ASCII characters", using
digraphs to create memorable passwords).
The idea of an "unforgeable character identifier" being assigned to a
process at creation time needed more explanation. How is this
identifier protected? Why is it unforgeable?
The idea of a sorted access control list was also presented. The list
was sorted because an access check stops at the first match, so more
general matches (including the "*" character) should be lower on the
list, otherwise they will catch all control checks. I found it rather
odd that the access control entries in the lists didn't have actions
associated with them. For example, user1 has the ability to read file1
while user2 has the ability to read/write the file. Instead the
abilities to act on a device or file were stored with the file itself.
This seemed like a lacking, basic feature in the protection system.
I also thought that the discussion of "capability" systems was useful.
The paper clearly enumerated the reasons why ACL's should be placed on
the underlying resource and not on the name itself. This issue still
manifests itself today in various security holes in web servers that
make assumptions based on the URL (the name or path) to a particular
resource, allowing hackers to circumvent the protection mechanism by
simply using another name to access the resource.
The ability to manage who a user gives access to a resource is a
difficult problem not solved by the Multics paper. This issue, commonly
known today as "Rights Management," goes beyond the single layer of
responsibility delegation. It would be nice to send out a document and
to be able to ensure that the only people who have access to the
document are in a particular group or division. This open problem is
mitigated today using various public key encryption mechanisms combined
with code obfuscation (definitely not an ideal solution, but acceptable
to many customers).
The idea of having every activity on the OS be generated by an actively
authenticated user is a useful one as well. Eventually, everything that
happens on the machine can be pinpointed to someone's decision.
Furthermore, the automated logout is another simple idea that has only
recently been implemented in Windows 2003...30 years after Multics
originated...
In the "Primary Memory Protection" section, the protection information
associated with the address descriptor would be a useful concept even
today to protect against such activities as stack buffer overruns. Why
should code pages on the x86 be writeable?
Finally, one of the weaknesses listed struck me as particularly true
even today. That is the "rush to get on the air" (i.e. our pressure to
ship), the lack of understanding (growing day by day as systems get more
complex), and the economics of shipping a secure product conflict with
the goal of designing a solid protection system. The relevant question
is, are people willing to pay for it upfront (before the next big
worm/virus destroys that all-important report)?
This archive was generated by hypermail 2.1.6 : Thu Jan 08 2004 - 17:35:17 PST