CMSC 414
Computer (and Network) Security
Lecture 14
Jonathan Katz
Midterm Review
Design Principles
(Chapter 13)
Overview
 Eight principles underlying design and
implementation of security mechanisms
 Described in an article by Saltzer and
Schroeder (1975)
– Still generally applicable today!
Key point I
 Simplicity
– Make designs/mechanisms easy to understand
– Less chance of error
– Example: (potentially) faulty implementation of
sendmail
– Example: (potential) inconsistencies in security
policy
Key point II
 Restriction
– Minimize the “power” of an entity
• E.g., only allow access to information it needs
• E.g., only allow necessary communication; restrict
type of communication allowed
– Less chance of harm!
Principle 1
 “Principle of least privilege”
– A subject should be given only the privileges it
needs to accomplish its task
– The function of a subject (not its identity)
should determine this
• I.e., if a subject needs certain privileges only to
complete a specific task, it should relinquish those
rights upon completion of the task
In practice…
 Systems are often not designed with the
necessary granularity
– E.g., “append” may not be distinct from “write”
– E.g., in UNIX, no access controls for root
• Anyone who can make backup files can also delete
files
Principle 2
 “Principle of Fail-Safe Defaults”
– Unless a subject is given explicit access to an
object, it should be denied access
– I.e., the default is no access
– E.g., a process reporting an error message
should not try to expand its rights in an attempt
to correct the error
Principle 3
 “Economy of Mechanism”
– Security mechanisms should be as simple as
possible…
– …but no simpler!
Consequences
 If design/implementation are simple, less
chance for error
 Software testing is also simpler
 Software interfaces especially suspect
– Typically make assumptions about the
input/output format of the other module
– E.g., finger protocol
Principle 4
 “Principle of Complete Mediation”
– All accesses to objects should be checked to
ensure they are allowed
– OS should mediate any request to read an
object --- even on the second such request by
the same subject!
Insecure examples…
– In UNIX, when a process tries to read a file, the
system checks access rights
– If allowed, it gives the process a file descriptor
– This file descriptor can be presented to the
kernel for access
– Note that if permissions are subsequently
disallowed, the process still has the valid file
descriptor!
• Insufficient mediation
Principle 5
 “Open Design”
– No “security through obscurity”
– Security of a system should not depend on the
secrecy of its implementation
• Of course, secret keys do not violate this principle!
Principle 6
 “Separation of Privilege”
– A system should not grant permission based on
a single condition
– E.g., require more than one sys admin to
implement a critical command
Principle 7
 “Principle of Least Common Mechanism”
– Minimize mechanisms depended upon by all
users
– Shared mechanisms are a potential information
path, and should not compromise security
– Any mechanism serving all users must satisfy
all users, a difficult task to achieve…
Principle 8
 “Psychological Acceptability”
– Security mechanisms should not make access to
the resource more difficult
– If mechanisms are too cumbersome, they will
not be used!
– Even if they are used, they may be used
incorrectly
– Password example…
Principles in Practice
Some terminology
 Trojan horse: program that appears to do
something useful, while in fact doing something
malicious
 Virus: program that copies itself into other (local)
programs
 Worm: program that copies itself over computer
networks, infecting programs/machines in remote
locations
Morris worm (1988)
 Exploited buffer overflow flaw in fingerd
 Also exploited flaw in sendmail
– Sendmail had root privilege when run in debug
mode
 Spread by guessing user passwords(!)
(Some) lessons?
 Complex programs (like sendmail) have
bugs
– Such programs should not run with high
privileges (i.e., root)
 Violations of principles?
– Principle of least privilege
– Separation of privilege
– Others?
Melissa virus/worm (1999)
 Word macro…
– When file opened, would create and send
infected document to names in user’s Outlook
Express mailbox
– Recipient would be asked whether to disable
macros(!)
• If macros enabled, virus would launch
(Some) lessons?
 Violations?
– Psychological acceptability (should users have
to decide whether to enable macros?)
– Principle of least privilege
– Open design?
– Others?
Chernobyl virus (1998)
 When infected program run, virus becomes
resident in memory of machine
– Rebooting does not help
 Virus writes random garbage to hard drive
 Attempts to trash FLASH BIOS
– Physically destroys the hardware…
(Some) lessons?
 Violations?
– Least privilege (why should the average user
ever need to write to the BIOS?)
– Fail-safe defaults
– Complete mediation
– Etc.