CMSC 414
Computer and Network Security
Lecture 17
Jonathan Katz
Reading on course webpage
 Buffer overflows
 Will get to it in about 2 weeks, but start reading
now
 Will be useful for HW3
System Security
“System security”
 Several meanings of “system security” here:
– Security of the entirety of what is being protected
– Operating-system security
– Host security
System security -- components
 Policy (specification)
– What security properties to focus on
– What is and is not allowed
 Mechanism (implementation)
– The mechanism enforces the policy
– Includes procedural controls, not just technical ones
• E.g., who may enter the room where backup tapes are stored
• How new accounts are established
– Prevention/detection/response/recovery
 Assurance (correctness)
– Verifying that the mechanism implements the policy
Security policy
 Formal statement of rules and practices that
specify what a system or organization will protect,
and how it will do so
 Useful to also specify threat model
Mechanisms for enforcing policy
 The precision of a mechanism measures how
closely the mechanism matches the policy
– E.g., an overly restrictive mechanism may prevent
things that are allowed by the policy
 Hard (in general) to develop a “maximally-
precise” mechanism for an arbitrary given policy
 Impossible (in general) to determine whether a
given mechanism implements a given policy
 Made worse by the fact that policy is often
specified informally to begin with
Assurance/evaluation
 The degree of confidence in the ability to carry out
the policy
 Encompasses both design and implementation
 Evaluation
– Examining computer/system with respect to certain
criteria
– Testing, formal analysis
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
Principle 1
 “Principle of least privilege”
– A subject should be given only the privileges it needs to
accomplish its task
• E.g., only allow access to information it needs
• E.g., only allow necessary communication
– The function of a subject (not its identity) should
determine this
• I.e., if a subject needs some privileges to complete a specific
task, it should relinquish those privileges upon completion
• 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
– More generally, in case of ambiguity the system should
default to the more restrictive case
Principle 3
 “Economy of Mechanism”
– Security mechanisms should be as simple as possible…
– This applies to both the policy and the mechanism!
– Less chance of error
– Can simplify assurance process
 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
– Time-of-check-to-time-of-use flaws…
 Good examples: re-authentication (on websites, or
systems) when performing sensitive tasks
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
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
• Minimize effect of a security flaw!
– Shared mechanisms are a potential information path,
and so may be used to compromise security
– Shared mechanisms 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
Access control
Multi-user vs. single-user systems
 Two kinds of multi-user systems
– Explicit awareness of other users (think unix file
systems)
– Users unaware of each other (think cloud computing)
– In either case, users’ files and applications must be
protected from illegal access by other users
 Single-user system
– Desktop PC
– Still don’t want one application to illegally access data /
memory belonging to another application
Multi-user vs. single-user systems
 ‘Classical’ computing was on a multi-user system
(time-sharing systems)
 Gradual shift to single-user systems (home PCs),
though multi-user systems were still used in
business, govt.
 More recently, momentum is going back to multi-
user systems (cloud computing)
Access control
 Determining who has access to specific files, or
other system resources
subject
request
reference allow/deny
object
monitor
Authentication vs. authorization
 Authentication
– Determining the identity of a user
– May also involve verification of IP address, machine,
time, etc…
– Determine whether a user is allowed to access the
system at all
– Used for audit, not just authorization
– We have already covered authentication protocols
 Authorization (access control)
– Assuming identity of user is known, determine whether
some specific action is allowed
Design considerations
 Where to implement access control?
Applications
Services/middleware
(DBMS*, object reference broker)
OS
(file/memory management, I/O)
Kernel
(mediates access to processor/memory)
Hardware
*Database
management system
Design considerations
 Access control generally must be implemented in
several layers
 For example:
– In the OS, access control done at the granularity of
files. But consider a (single file containing a) grades
spreadsheet: the application will have to ensure that
each student can only read their own grade (while the
instructor can read and write everything)
Some terminology
 Protected entities: “objects” O
 Active objects: “subjects” S (i.e., users/processes)
– Note that subjects can also be objects
– Typically, each subject associated with some
principal/owner
 Subjects/objects can be:
– Users
– Files
– Processes
– System resources (servers, printers, etc.)
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}
Access control matrix
 The access control matrix provides a useful way to
think about the rights in the system
 It can also be a way to implement access control
subject
request
reference allow/deny
object
monitor
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
Granularity
 Granularity is an issue at the level of subjects,
objects, and rights
 In theory, arbitrary level of granularity, e.g.,
– Subjects: functions within processes
– Objects: characters within files
– Rights: write, append, increment-only, …
 In practice, a decision must be made as to the level
of granularity that will be supported
Granularity
 Trade-off is obvious:
– Fine-grained access control gives “better security”
• Least privilege
– Coarse-grained access control more efficient