From: Gang Zhao (galaxy_at_cs.washington.edu)
Date: Wed Jan 07 2004 - 16:01:55 PST
The exciting feature discussed in this paper is the access control lists.
The design principals that are enumerated seem to appear largely unchanged in every book on secure programming. I find it immensely reassuring that these principals have remained largely unchanged in the last quarter century:
1. Permission rather than exclusion.
2. Check every access
3. No security through obscurity
4. Principle of least privilege.
5. Make it easy for users to be secure.
Of these, only the 2nd might be called into question. On networks where the security groups are centralized on a distant server it might be infeasible to check whether an employee has been fired every time they create a text file.
While the concept of the security group is discussed, it is unclear whether one security group may be made a member of another.
Compartments are an interesting feature. The user overhead for their use seems to be a bit high.
It is interesting to note the use of the term "borrowing unaudited programs", which shows the way that the copyright and expectations of copyright have changed over the years.
While the article tangentially discusses privacy, the line drawn seems quite different than the contemporary line. The privacy line includes preventing users from knowing the identity of other users.
The naming scheme discussed again is infeasible for a large network, "requiring all user names, once registered, to be permanent"
This article was clearly written during communist paranoia, "The... lists... would be especially useful... since they would help in the construction of a list of items a defector might have had access to."
The batch authentication seems to be the predecessor of remote access.
The list of weaknesses seems to be the same weaknesses that we see today, but on a different scale.
It was considered infeasible to audit 300 modules of 200 lines of source code. While the numbers have changed over 25 years, the result remains the same.
Three reasons for size of the protected area sound very familiar:
Economics, development time constraints, and lack of understanding.
This archive was generated by hypermail 2.1.6 : Wed Jan 07 2004 - 16:02:00 PST