Protection of Information
- Summary: the paper surveys techniques and insights on the protection of
computer-resident information, i.e. authorization, authentication, and access
- There's a wonderful glossary.
- Levels of protection: no protection, complete isolation, controlled
sharing, user-programming sharing controls, tagging of information. Dynamics
of use considered important.
- Design principles for security: (a fabulous section of the paper!)
- Economy of mechanism: keep it simple and small.
- Fail-safe defaults: default should be lack of access.
- Complete mediation: all accesses must be verified.
- Open design: "security through obscurity" doesn't work.
- Separation of privilege.
- Least privilege: principals should get only the priviliges they
legitimately need, and no others.
- Least common mechanism: minimize shared mechanism. (?)
- Psychological acceptability: users will find a way around your
protection mechanism if it is too inconvenient to use. Also, user interface
to protection mechanism should roughly match the user's mental image;
otherwise mistakes will creep in.
- Work factor: security is economics; just have to make the cost of
breaking security high enough to deter intruders.
- Compromise detection: (aka intrusion detection) analysis of audit logs
to detect (rather than prevent) violations of the security policy.
- Common mechanisms: descriptions, supervisor mode, hardware access
checking. You already know all this stuff.
- Authentication: passwords ("something you know"), eavesdropping, physical
tokens ("something you have"), bio-identification ("something you are", e.g.
fingerprints), server spoofing, cryptography.
- Access control lists and capabilities for more flexible protection. (in
the paper's terminology, list-oriented vs. ticket-oriented.)
- Detailed examples of descriptor-based protection systems. A largely boring
& outdated section of the paper; here are the interesting bits:
- Capabilities. Can be implemented with hardware support by tagging (or
else in software with crypto). Do access checks at initial bind time; then
the capability can be used, copied, shared freely. Thus capabilities can be
very efficient, since access check need only be done at initial bind time.
Disadvantage is that revocation and propagation control gets really hard.
- Access control lists. Objects have an ACL associated with them that says
who can get what access to the object. Revocation, etc. get easy, but
performance suffers since the heavy-weight access check is performed at
- Hybrid systems: use access control lists at a high level; principals who
pass the ACL check are given a capability.
- Discretionary vs. mandatory access control (MAC). Discretionary controls
are those the owner of an object imposes on his object; mandatory are those
the system imposes on all objects. MAC typically used in military systems:
all data has a classification, and no principal may leak Top Secret data to
a compartment with lower classification. Lots of surprising theoretical
difficulties with MAC; covert channels hard to eliminate.
- Protected subsystem: collection of objects, which others can access to
only through designated entry points. Allows user-specified programmable
- State of the art: (in those days)
- Most systems didn't provide much security, or only recently began
worrying about protection. Not much distinction made between hardware
architectures and software operating systems.
- Research directions: assurance, fault-tolerance, constraints on use of
information after release (e.g. MAC), cryptography, authentication.