CMSC 414
Computer and Network Security
Lecture 9
Jonathan Katz
Announcements
 Midterm on March 6
– Will cover material through March 4
– Anyone using DSS please speak to me after class
 Next homework out later this week
System Security
System security
 General principles
 Access control, access control policies
 Trusted computing
 Memory protection
System security -- components
 Policy (specification)
– Important to specify
– Consider various tradeoffs
 Mechanism (implementation)
– Prevention
– Detection
– Response
– Recovery
 Assurance
– Verifying that the mechanism implements the policy
Security policy
 Security policy classifies system states as “secure”
or “insecure”
– “System state” may potentially include everything…
– In practice, a full specification of this sort is impossible
 A secure system starts in a “secure” state and
cannot enter an “insecure” state
– “Breach of security” occurs when a system enters an
“insecure” state
 Policy may also indicate other desirables
– Availability, confidentiality
Security mechanism
 A security mechanism enforces (part of) the
security policy
 Includes procedural/operational controls, not just
technical controls
– E.g., who may enter the room in which backup tapes
are stored
– How new accounts are established
Mechanisms for enforcing policy
 The precision of a mechanism is a measure of how
overly-restrictive the mechanism is with respect to
the policy
– I.e., due to preventing things that are allowed
 Unfortunately, impossible (in general) to develop
a “maximally-precise” mechanism for an arbitrary
given policy
Security Principles
General principles
 Seminal article by Saltzer and Schroeder (1975)
– Linked from the course homepage
 Eight principles underlying design and
implementation of security mechanisms
 These are guidelines, not hard and fast rules
 Not exhaustive
Key point I
 Simplicity
– Make designs/mechanisms/requirements easy to
understand and use
– This applies to both the policy and the mechanism!
– Less chance of error
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 privileges upon
completion of the task
• If reduced privileges are sufficient for a given task, the subject
should request only those privileges
In practice…
 There is a limit to how much granularity a system
can handle
 Systems are often not designed with the necessary
granularity
– E.g., “append” may not be distinct from “write”
– E.g., in UNIX, nothing between user and root
• Anyone who can make backup files can also delete those 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
Principle 3
 “Economy of Mechanism”
– Security mechanisms should be as simple as possible…
– …but no simpler!
– Can simplify formal proofs of security (or even
informal audits)
Rationale
 If design/implementation are simple, less
chance for error
 Software testing is also simpler
 Offering too much functionality can be dangerous
– E.g., finger protocol: cap how much information can be
returned, or allow an arbitrary amount?
• DoS attack by returning an infinite stream of characters
– E.g., macros in Excel, Word
– E.g., postscript can execute arbitrary code
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!
• Don’t cache authorization results
• Don’t rely on authentication/authorization performed by
another module
Insecure example…
 In UNIX, when a process tries to read a file, the
system checks access rights
– If allowed, it gives the process a file descriptor
– File descriptor is presented to OS for access
 If permissions are subsequently revoked, the
process still has a valid file descriptor!
– Insufficient mediation
Insecure example
 Race condition
– E.g., consider what happens if reading a file is done as:
• if (allowed(user, “r”, memory_location(filename)) then
allow(user, “r”, memory_location(filename))
• What if memory_location(filename) changes in the interim?
– A related flaw was present in early versions of unix
Secure examples
 Re-authentication on amazon.com
 Re-authentication to change password
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”
– (As much as is feasible…) a system should not grant
permission based on a single condition
– E.g., require more than one sys admin to issue a critical
command, or more than one teller to issue an ATM card
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
– Also expose the system to potential DoS attacks
Principle 8
 “Psychological Acceptability”
– Security mechanisms should not make access to the
resource more difficult
– If mechanisms are too cumbersome, they will be
circumvented!
– Even if they are used, they may be used incorrectly
Principles in Practice
Morris worm (1988)
 Exploited buffer overflow flaw in fingerd
 Also exploited flaw in sendmail
– Sendmail had root privilege when run in debug mode
 Violations?
– Principle of least privilege
– Separation of privilege
– Economy of mechanism (sendmail program too
complex!)
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
 Violations?
– Psychological acceptability (should users have to
decide whether to enable macros?)
– Principle of least privilege
– Open design?
– Others?
OS Security
Overview
 Traditional OS security motivated by multi-user
systems where users are aware of each other
– E.g., unix
– This is what we focus on in this segment
 There is a movement away from such systems
– Computing done on desktop PC, and/or on a remote
(shared) server but without “awareness” of other users
– How do you share files with your friends?
• Email file
• Email web link to file
• P2P model
Differences
 In multi-user context, threats are unauthorized
reading/modification of files, or unauthorized use
of system resources by legitimate users
 In desktop PC context, the threat is having a virus
take control of your machine (applies to
administrators of remote servers as well)
 In remote server context, the threat is unauthorized
use of systems resources by legitimate users
– This setting can also be viewed as a simplified multiuser setting (“regular” users vs. sys admins)
Here…
 Our focus here is on multi-user systems
 These are still used in business environments
(shared files, shared databases, etc.)
Authentication vs. authorization
 Authentication
– Determining the identity of a user
– May also require verification of IP address,machine,
time, etc…
– Determine whether a user is allowed to access the
system at all
– We will return to this later; for now we assume it
 Authorization
– Assuming the identity of the user is known (and the
user is allowed to access the system), determine
whether some specific action is allowed
Access control
Some terminology
 Protected entities: “objects” O
 Active objects: “subjects” S (i.e., users/processes)
– Note that subjects can also be objects
 Subjects/objects can be:
– Files
– Processes
– Servers
– Functions/variables (within a program)
– Database entries
– System resources (printers, etc.)
General principles
 Fine-grained access control is better
– E.g., control access to files not just directories
 Least privilege
– Grant minimum abilities necessary to complete task
 Closed vs. open policies
– Closed = disallowed unless explicitly allowed
– Open = allowed unless explicitly disallowed
 Conflict resolution
– Prevent conflicts, or know how to deal with them
Access control policies
 Discretionary access control (DAC)
 Mandatory access control (MAC)
 Role-based access control (RBAC)
 Not necessarily mutually exclusive
– A system may use different mechanisms for different
resources
– Or, apply two policies; allow access only if both allow
DAC
 Controls based on the identity of the user and
access rules
 Rights can be delegated at users’ discretion
 Most common
MAC
 Controls based on comparing security labels with
security clearances
 Delegation not allowed
 Primarily used in military applications
RBAC
 Controls based on a user’s (or program’s) role, not
their identity
 User’s rights can change depending on their
current role
 More recent proposal
Discretionary access control
Access control matrix
 Matrix indexed by all subjects and objects
– Characterizes rights of each subject with respect to each
object
 Formally: set of objects O and subjects S, set of
possible rights
 Matrix A with subjects labeling the rows and
objects labeling the columns
– The entry (s,o) contains the rights for s on o
– Examples: read/write/execute/etc.
Example
Objects
Subjects
File 1
File 2
User 1
{r,w}
{w}
User 2
{w}
{w}
File 3
…
File n
{r,w}
{r,w}
User 3
{r}
{w}
{r}
{w}
…
User k
{r}
{r}
{r,w}
More complex access control
 In general, “rights” may be functions
– “Actual” rights depend on the system state
– Equivalently, may depend on system history
 Rights can form hierarchies
– E.g., right X implies right Y
 How fine-grained the access control is depends on
how fine-grained the rights are
– E.g., “write” vs. “append-only”
Coarse-grained access control
 Access control can also be more coarse-grained
than a full-blown access matrix would imply
 E.g., in unix:
– For a file, specify access rights for the owner, the group
to which the owner belongs, and everyone else
– Possible rights are: read, write, execute