Transcript Security and Authentication-

Security and Authentication
(continued)
CS-502, Operating Systems
Fall 2009 (EMC)
(Slides include materials from Modern Operating Systems, 3rd ed., by Andrew Tanenbaum and from
Operating System Concepts, 7th ed., by Silbershatz, Galvin, & Gagne)
CS-502 (EMC) Fall 2009
Security and
Authentication
1
Reading Assignment
• Tanenbaum, Modern Operating Systems, 3rd
edition, Chapter 9
– Security and threats
– Viruses
• How to write and detect!
– Protection – implementation of security
CS-502 (EMC) Fall 2009
Security and
Authentication
2
Outline
• A puzzle – who am I talking to?
• The first computer virus
• Some program threats
• Overview of protection mechanisms
• Security Policies
• Fun with cryptography
CS-502 (EMC) Fall 2009
Security and
Authentication
3
Reminder
• Protection:
• Mechanisms and policy to keep programs and users
from accessing or changing stuff they should not do
• Internal to OS
• §9.1-9.3 in Tanenbaum
• Security:
• Issues external to OS
• Authentication of user, validation of messages,
malicious or accidental introduction of flaws, etc.
• §9.4-9.8 in Tanenbaum
CS-502 (EMC) Fall 2009
Security and
Authentication
4
Goals of Protection
• Operating system consists of a collection of
objects (hardware or software)
• Each object has a unique name and can be
accessed through a well-defined set of operations.
• Protection problem – to ensure that each object is
accessed correctly and only by those processes
that are allowed to do so.
CS-502 (EMC) Fall 2009
Security and
Authentication
5
Guiding Principles of Protection
• Principle of least privilege
– Programs, users and systems should be given
just enough privileges to perform their tasks
• Separate policy from mechanism
– Mechanism: the stuff built into the OS to make
protection work
– Policy: the data that says who can do what to
whom
CS-502 (EMC) Fall 2009
Security and
Authentication
6
Domain Structure
• Access-right = <object-name, rights-set>
where rights-set is a subset of all valid operations
that can be performed on the object.
• Domain = set of object-right pairs
CS-502 (EMC) Fall 2009
Security and
Authentication
7
Domain – Examples
• User
– An actual human, or a name of a system role
• e.g, uucp, root
– Rights list what the “user” can do
• A team
– Working on a project
See Tanenbaum, §9.3.1
CS-502 (EMC) Fall 2009
Security and
Authentication
8
Conceptual Model
• View protection as a matrix (Access Matrix)
• Rows represent domains
• Columns represent objects
• Access(i, j) is set of operations that process
executing in Domaini can invoke on Objectj
CS-502 (EMC) Fall 2009
Security and
Authentication
9
Textbook Access Matrix
• Columns are access control lists (ACLs)
• Associated with each object
• Rows are capabilities
• Associated with each user, group, or domain
CS-502 (EMC) Fall 2009
Security and
Authentication
10
Textbook Access Matrix (continued)
• Domains themselves are objects
– Can be added to Access Matrix
CS-502 (EMC) Fall 2009
Security and
Authentication
11
Unix & Linux
• System comprises many domains:–
–
–
–
–
Each user
Each group
Kernel/System
Specific system processes & responsibilities
• (Windows has even more domains than
this!)
CS-502 (EMC) Fall 2009
Security and
Authentication
12
Unix/Linux Matrix
file1
file 2
file 3
device
domain
User/Domain 1 r
rx
rwx
–
enter
User/Domain 2 r
x
rx
rwx
–
User/Domain 3 rw
…
–
–
–
–
• Columns are access control lists (ACLs)
• Associated with each object
• Rows are capabilities
• Associated with each user or each domain
CS-502 (EMC) Fall 2009
Security and
Authentication
13
Changing Domains (Unix)
• Domain = uid or gid
• Domain switch via file access controls
– Each file has associated with it a domain bit (setuid bit).
• rwS instead of rwx
– When executed with setuid = on, then uid or gid is
temporarily set to owner or group of file.
• I.e., process has entered the domain of the user or group
– When execution completes uid or gid is reset.
• Separate mechanism for entering kernel domain
– System call interface
CS-502 (EMC) Fall 2009
Security and
Authentication
14
Practicalities
• At run-time…
– What does the OS know about the user?
– What does the OS know about the resources?
• What is the cost of checking and enforcing?
– Access to the data
– Cost of searching for a match
• Impractical to implement full Access Matrix
– Size
– Access controls disjoint from both objects and domains
CS-502 (EMC) Fall 2009
Security and
Authentication
15
ACLs vs. Capabilities
• Access Control List: Focus on resources
– Good if resources greatly outnumber users
– Can be implemented with minimal caching
– Good when the user who creates a resource has
authority over it
• Typically attached to objects
– E.g., file metadata
– Control mechanism checks if user/process fits one of
the classes of usage
CS-502 (EMC) Fall 2009
Security and
Authentication
16
ACLs vs. Capabilities (continued)
• Capability System: Focus on users
– Good if users greatly outnumber resources
– Lots of information caching is needed
– Good when a system manager has control over all
resources
• Like a system of (unforgeable) tickets
– Domain/user must present a ticket to get access to a
particular object or class of objects
– Especially useful in distributed systems
– Issue: can a capability be revoked once it is given out?
CS-502 (EMC) Fall 2009
Security and
Authentication
17
Both are needed
• ACLs for files and other proliferating resources
• Capabilities for major system functions
• The common OSs offer BOTH
– Linux emphasizes an ACL model
• provides good control over files and resources that are file-like
– Windows 2000/XP/Vista emphasize Capabilities
• provides good control over access to system functions (e.g.
creating a new user, or doing a system backup…)
• Access control lists for files
CS-502 (EMC) Fall 2009
Security and
Authentication
18
…and good management, too!
• What do we need to know to set up a new
user or to change their rights?
• …to set up a new resource or to change the
rights of its users?
• …Who has the right to set/change access
rights?
• No OS allows you to implement all the
possible policies easily.
CS-502 (EMC) Fall 2009
Security and
Authentication
19
Enforcing Access Control
• User level privileges must always be less than OS
privileges!
– For example, a user should not be allowed to grab
exclusive control of a critical device
– or write to OS memory space
• …and the user cannot be allowed to raise his
privilege level!
• The OS must enforce it…and the user must not be
able to bypass the controls
• In most modern operating systems, the code which
manages the resource enforces the policy
CS-502 (EMC) Fall 2009
Security and
Authentication
20
(Traditional) Requirements–System Call Code
• No user can interrupt it while it is running
• No user can feed it data to make it
– violate access control policies
– stop serving other users
• No user can replace or alter any system call
code
• No user can add functionality to the OS!
• Data must NEVER be treated as code!
CS-502 (EMC) Fall 2009
Security and
Authentication
21
“Yeah, but …”
• No user can interrupt it while it is running
• Windows, Linux routinely interrupt system calls
• No user can feed it data to make it
• violate access control policies
• stop serving other users
• No user can replace or alter any system call code
• Except your average virus
• No user can add functionality to the OS!
• Except dynamically loaded device drivers
• Data must NEVER be treated as code!
• “One man’s code is another man’s data” A. Perlis
CS-502 (EMC) Fall 2009
Security and
Authentication
22
Saltzer-Schroeder Guidelines
•
•
•
•
System design should be public
Default should be no access
Check current authority – no caching!
Protection mechanism should be
– Simple, uniform, built into lowest layers of system
• Least privilege possible for processes
• Psychologically acceptable
• KISS!
CS-502 (EMC) Fall 2009
Security and
Authentication
23
Questions?
CS-502 (EMC) Fall 2009
Security and
Authentication
24
Outline
• A puzzle – who am I talking to?
• The first computer virus
• Some program threats
• Overview of protection mechanisms
• Security Policies
• Fun with cryptography
CS-502 (EMC) Fall 2009
Security and
Authentication
25
What is a “Security Policy?”
• What rights MAY a user have?
– Define the maximum!
• What rights can a user pass on?
• How can a user acquire additional rights?
• Linux/Unix:
CS-502 (EMC) Fall 2009
-rwxr-xr-- /foo
-rw--w---- /bar
Security and
Authentication
26
Policy Models (1)
A “Policy Model” is a framework for creating
a specific policy for a specific organization
• Linux/Unix
–
–
–
–
Users, groups, everybody
“owner” (or “…”) controls grant of rights
Rights based on UID, GID – Focus on files
Process has rights of parent
• can change GID or drop rights
CS-502 (EMC) Fall 2009
Security and
Authentication
27
Policy Models (2)
• Win200X
– Users and groups
– Groups may be members of groups
– Rights are the combined rights of all groups of
which the user is a direct or indirect member
– Administrator controls everything
• can grant any right
– The default is strong control over admin
functions and little control over files
CS-502 (EMC) Fall 2009
Security and
Authentication
28
Policy Models (3)
• Typical Business
– Managers can (usually) grant rights to their staff
– Information is visible to people above in the
organization
– Managers do not have authority to grant access
downward for some classes of information
– Overall control is maintained by restricting access to
applications rather than to data
– Databases have their own distinct access controls
CS-502 (EMC) Fall 2009
Security and
Authentication
29
Policy Models (4)
• The Military Mind
– Access rights are granted only by a higher
authority
– Access is broken into two models
• need-to-know (usually organizational with upward
visibility)
• item-by-item (classification may occur in advance of
creation or after)
– Creator may be denied access to own work
– Some weird anomalies
CS-502 (EMC) Fall 2009
Security and
Authentication
30
Policy Models (5)
• The BMA (British Medical Assoc.) model (1995)
– Each medical record has an access control list
– Access may be granted to a new clinician by the subject
or the primary clinician
– Patient must be notified of all ACL changes, and may
revoke access
– Deletions are not allowed
– All access must be logged and auditable
– Information may be aggregated from A into B only if
ACL(A) is a superset of ACL(B)
• Reference
Anderson, Ross, “An Update on the BMA Security Policy,”
1996. (.pdf)
CS-502 (EMC) Fall 2009
Security and
Authentication
31
Policy Models (6)
• The HIPAA model (1998)
– The patient controls the right to access
“personally identifiable health information”
– Access is granted to any clinician or facility
staff participating in the care of the patient
– Patient must be notified of all breaches
– Deletions are not allowed
– All access must be logged and auditable
– Privileges may be revoked
CS-502 (EMC) Fall 2009
Security and
Authentication
32
More Principles
• Think about Assets, Threats and
Vulnerabilities FIRST
• Find an appropriate (and minimally
complex) Policy Model
• Match your OS capabilities to the policy
model as best you can
• Train staff to recognize social engineering!
• Train staff to make a habit out of the policy!
CS-502 (EMC) Fall 2009
Security and
Authentication
33
Questions?
CS-502 (EMC) Fall 2009
Security and
Authentication
34
Resources
• Network World Security Newsletter
– http://www.nwsubscribe.com
– Practical advice, not a virus alert newsletter. Especially good for
the links to other security resources at the bottom of each article
• CERT Coordination Center at CMU
– http://www.cert.org
• News about system threats, including viruses and other
problems. Source for OCTAVE papers and process
• Norton AntiVirus Site (Symantec)
– http://securityresponse.symantec.com/avcenter/
• McAfee Security (Network Associates)
– http://us.mcafee.com/virusinfo/
CS-502 (EMC) Fall 2009
Security and
Authentication
35
Textbooks
Network Security: C. Kaufman, R. Perlman, M. Speciner,
Prentice Hall (2002)
– A practical but rigorous presentation of network security issues and
techniques with emphasis on cryptographic solutions
Security Engineering: R. Anderson, Wiley (2001)
– Focused on learning from past mistakes in security system design.
– Excellent discussion of policies and policy models.
– See author’s web site (www.ross-anderson.com) if you are
interested in current research.
CS-502 (EMC) Fall 2009
Security and
Authentication
36
Other Books
Real World Linux Security: R. Toxen, Prentice Hall (2003)
– An excellent read. Lists hundreds of vulnerabilities and what to do
about them. Valuable for non Linux users too.
Windows 2003 Security Bible: B. Rampling, Wiley (2003)
– Good example of a how-to book. Specific to WIN2003
The Art of Deception: K. Mitnick, Wiley (2002)
– Mitnick is one of the most famous social engineers.
– Must-read for those involved in broad security planning, and fun
for everyone.
CS-502 (EMC) Fall 2009
Security and
Authentication
37