CMSC 414 Computer and Network Security Lecture 9

1
CMSC 414Computer and Network SecurityLecture 9

• Jonathan Katz

2
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

3
System Security
4
System security

• General principles
• Access control, access control policies
• Trusted computing
• Memory protection

5
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

6
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

7
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

8
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

9
Security Principles
10
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

11
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

12
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!

13
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

14
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

15
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

16
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)

17
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

18
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!
• Dont cache authorization results
• Dont rely on authentication/authorization
  performed by another module

19
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

20
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(filen
  ame))
• What if memory_location(filename) changes in the
  interim?
• A related flaw was present in early versions of
  unix

21
Secure examples

• Re-authentication on amazon.com
• Re-authentication to change password

22
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!

23
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

24
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

25
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

26
Principles in Practice
27
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!)

28
Melissa virus/worm (1999)

• Word macro
• When file opened, would create and send infected
  document to names in users 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?

29
OS Security
30
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

31
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
  multi-user setting (regular users vs. sys
  admins)

32
Here

• Our focus here is on multi-user systems
• These are still used in business environments
  (shared files, shared databases, etc.)

33
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

34
Access control
35
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.)

36
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

37
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

38
DAC

• Controls based on the identity of the user and
  access rules
• Rights can be delegated at users discretion
• Most common

39
MAC

• Controls based on comparing security labels with
  security clearances
• Delegation not allowed
• Primarily used in military applications

40
RBAC

• Controls based on a users (or programs) role,
  not their identity
• Users rights can change depending on their
  current role
• More recent proposal

41
Discretionary access control
42
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.

43
Example
File 1 File 2 File 3 File n
User 1 r,w w r,w
User 2 w w r,w
User 3 r w

User k r r r,w r w
44
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

45
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