Download Security

Course Overview
Principles of Operating Systems







Introduction
Computer System
Structures
Operating System
Structures
Processes
Process Synchronization
Deadlocks
CPU Scheduling
© 2000 Franz Kurfess








Memory Management
Virtual Memory
File Management
Security
Networking
Distributed Systems
Case Studies
Conclusions
Security 1
Chapter Overview
Security



Motivation
Objectives
Protection



protection of resources
protection methods
Access Control
© 2000 Franz Kurfess

Security




threats
protection mechanisms
Important Concepts and
Terms
Chapter Summary
Security 2
Motivation
 computer
systems may be of considerable value
and must be protected from damage
 hardware, software, and stored data may be
essential for the performance of tasks and need to
be available when needed
 system objects need to be protected from
inadvertent unauthorized access or use
 there is the possibility of intrusion, modification,
deletion, etc. with malicious intent
© 2000 Franz Kurfess
Security 3
Objectives
 know
basic protection methods and mechanisms
 be aware of the most common threats to system
security
 evaluate tradeoffs between performance, ease of
use, flexibility, etc. on one hand and security on the
other hand
© 2000 Franz Kurfess
Security 4
Protection
 methods
and mechanisms that check the legality of
an operation on an object in the computer system
 legality refers to
 the
authorization to perform an operation
 the appropriate use of an operation
 the validity of the parameters
 objects
can be
 hardware
components
 software entities


OS components, user programs
files, processes, pipes, etc
 data
© 2000 Franz Kurfess
Security 5
Policy vs. Mechanism
 protection
= policy + mechanism
 policy
 set
of rules implemented by a mechanism
 determined by the management of the system
 mechanism
 means
for accomplishing a task
 used for implementing and enforcing a policy
© 2000 Franz Kurfess
Security 6
Computer Objects
 objects
in a computer system that need to be
protected
 hardware objects

CPU, memory segments, hard disk, printers, tape drives,
etc.
 software

objects
files, processes, databases, semaphores, pipes, etc.
© 2000 Franz Kurfess
Security 7
Protection Domain
a
domain is a set of rights to perform certain
operations on certain objects
 specified as (objects, rights) pairs
 each
pair specifies an object and operations that can be
performed on the object
 limit
and control access of processes
 to
objects they are authorized to use
 only with operations they are authorized for
© 2000 Franz Kurfess
Security 8
Minimum Privilege Principle
a
process should have only the capabilities needed
to perform its task
a
protection domain must be tailored to each individual
process
 not practical for most systems
 in practice, processes with similar domains are grouped
together
© 2000 Franz Kurfess
Security 9
Protection Domains in UNIX
 the


domain of a process is determined by
its user id (uid)
its group id (gid)
a
process may switch temporarily between different
domains
 e.g.
to execute a program owned by another user
 this is a security problem, especially when user processes
switch to the root domain
© 2000 Franz Kurfess
Security 10
Access to Resources
 computer
system resources
 hardware


deliberate or accidental damage, theft, unauthorized use
physical access to hardware may be restricted
 software


execution, modification, deletion, unauthorized copying
restricted privileges, configuration management
 data


modification or destruction, unauthorized use
restricted privileges, encryption, off-line storage
 communication


eavesdropping, traffic analysis, intrusion, forging of messages,
denial of service
prevention, detection, encryption, isolation
© 2000 Franz Kurfess
Security 11
Access Control
 subject
 entity
requesting access
 usually a process (UID and GID on UNIX)
 users are represented by processes
 object:
 entity
to be accessed
 CPU, memory, network, files, programs
 access

right
operations the subject is allowed to perform on the object
© 2000 Franz Kurfess
Security 12
Unix Access Control
 subjects
 divided

into three domains
user, group and others (not user)
 objects
 primarily
files
 access to devices through the file system
 access

rights
three types



read
write
execute
© 2000 Franz Kurfess
Security 13
Access Matrix
 specifies
for each domain and each object the
permissible operations
 rows
hold domains
 objects are in the columns
 entry
access(i,j)
 specifies
the set of operations that a process executing in
domain Di can perform on object Oj
© 2000 Franz Kurfess
Security 14
Access Matrix Diagram
 the
operations specified in the entry are allowed for
processes in a certain domain for a particular object
File1 File2 File3 Printer
Domain 1
r
rw
rx
2
3
© 2000 Franz Kurfess
r
w
Security 15
Domain Switching in
an Access Matrix
 switching
between domains can also be controlled
by the access matrix
 additional
columns for the target domain
File1 File2 File3 Printer
Domain 1 r
rw
2
3
© 2000 Franz Kurfess
D1
D2
D3
switch
rx
r
w
switch
Security 16
Implementation of Access
Matrices
 global
table
 access lists
 capability lists
© 2000 Franz Kurfess
Security 17
Global Table
 set
of ordered triplets
<domain, object, rights>
 for
each operation of a subject on an object, the
table is searched for a triplet such that
 the
subject must be in the domain
 the object must be present
 the operation must be part of the rights
 advantage
 simple
realization
 drawbacks
 large
tables, requiring virtual memory or I/O operations
 groupings of entries not possible
© 2000 Franz Kurfess
Security 18
Access Control Lists
 each
object has a list of pairs with (domain, access
rights)
 specifies
which operations may be performed by which
entity
 columns
are implemented as lists
 only non-empty entries are stored
 used in the VMS operating system
© 2000 Franz Kurfess
Security 19
Example
 File1:
(john, rw)
 File2: (mary, rwx)
 File3: (john, r), (mary, rw), (fred, rx)
 File4: (*, rx)
 File5: (fred, -), (*, rw)
© 2000 Franz Kurfess
Security 20
Capability List
 for
each domain in the access matrix we associate a
list of objects along with the type of access for each
object
 each row is implemented as a list
 objects
within a domain
 operations allowed on the objects
a
process presents the capability for an operation to
the OS before the operation is performed
 maintained by the OS, not directly accessible to the
users
© 2000 Franz Kurfess
Security 21
Example
Type Rights
Object
0 File r w -
Pointer to file2
1 File r - x
2 File r w x
Pointer to file1
Pointer to file3
3 File - w -
Pointer to file4
© 2000 Franz Kurfess
Security 22
Comparison

access lists



correspond directly to the
needs of the users
determining access rights for
a particular domain is difficult
permissions for all objects
must be specified


frequently a default list is
used, and only deviations are
noted explicitly
every access to an object
must be checked


capability lists




do not correspond directly to
the needs of the users
useful for finding information
on a particular process
revocation of capabilities may
be inefficient
not very frequently used in
their pure form

sometimes used as cache for
information in the access list
requires a search of the
access list
© 2000 Franz Kurfess
Security 23
Modification of Access Rights
 permissions
for operations on objects may change
dynamically in a system
 this can lead to the extension or revocation of
access rights
 easy with an access-list scheme
 corresponding
 difficult
rights are modified
with capability lists
 capabilities
are distributed throughout the system, and
must be found first
© 2000 Franz Kurfess
Security 24
Authorization
 granting
of permissions for operations on objects to
subjects
© 2000 Franz Kurfess
Security 25
Authentication
 users
 other
systems
© 2000 Franz Kurfess
Security 26
User Authentication
 identification
of users at login time
 an be addressed through
 passwords
 physical
© 2000 Franz Kurfess
identification
Security 27
Passwords
 legitimate
users identify themselves by providing an
account id and a password
 if
the password matches the one stored in the system, the
user is considered legitimate
 the
password must be kept secret
 must
not be exposed by the user
 must be stored internally in encrypted format or in a
protected place
 easy
to understand and use
 low implementation overhead
© 2000 Franz Kurfess
Security 28
Password Problems
 often
easy to defeat
 password
guessing with the use of a list of likely words
 watching while the user types the password (shoulder
surfing)
 network sniffing
 account sharing
© 2000 Franz Kurfess
Security 29
Example Password Cracking
 7-character
passwords chosen from a 95 printable
character set: 957 (or 7x1013 approx.)
 at 1000 encryption/sec it will take 2000 years to
create the complete list
© 2000 Franz Kurfess
Security 30
Password Secrecy
 extension
and encryption
 associate

an n-bit random number with each password
the number is stored in the password file unencrypted
 the
password and the random number are first
concatenated and then encrypted together and stored in
password file
 increases the size of the possible passwords by 2N
© 2000 Franz Kurfess
Security 31
Passwords Provisions
 system-generated
passwords
 random,
easy to remember, but nonsense words (i.e.
vriendly) are generate by the system
 regular
 may



change of passwords
defeat the purpose
users write down passwords
toggling between passwords
use of month/year in the password
 paired
passwords
 users
provide a list of questions and answers that will be
stored in encrypted format
 the system randomly selects an entry which the user has
© 2000 Franz
Kurfess
Security 32
to complete
One-Time Passwords
 each
password can be used only once
 frequently
based on special hardware calculators or code
books to determine the one-time password
 complicated to administer
© 2000 Franz Kurfess
Security 33
Physical Identification
 plastic
card with magnetic stripe and password
(cash machines)
 often
augmented by personal identification numbers (PIN)
 fingerprints,
voice prints, visual recognition
 signature
© 2000 Franz Kurfess
Security 34
Security
 application
of protection methods and mechanisms
to maintain the safe operation of a computer system
 must also take into account the external
environment of the system
 cannot rely on orderly behavior of users and
processes
 users
may try to circumvent protection mechanisms
© 2000 Franz Kurfess
Security 35
Security Aspects
 physical
security
 prevention
of unauthorized access to physical systems
 restriction to legal use of systems
 operational
 subjects
© 2000 Franz Kurfess
security
may only execute legal operations on objects
Security 36
Security Threats
 technical
 interruption
 interception
 modification
 fabrication
 nontechnical
© 2000 Franz Kurfess
(“social engineering”)
Security 37
Security Threats in OSes
 most
operating systems have major security
problems
 penetration teams can be used to test security and
expose problems
© 2000 Franz Kurfess
Security 38
Common Attack Methods
 snooping
and sniffing
 listening
in on network traffic
 ask for memory pages, disk space or tapes and just read
them (don't fill them)

 trial
many systems don’t delete old information
and error on system calls
 illegal
system calls, legal system calls with illegal
parameters, or legal system calls with legal but
unreasonable parameters
 example: “ping of death” attack
 login
interrupt
 start
logging in and then hit DEL RUBOUT BREAK (or
© 2000 Franz Kurfess
Security 39
Attack Methods (Cont.)
 OS
meddling
 modify
 do
complex OS data structures residing in memory
don’ts
 look
for manuals that say Do not do X and try as many
combinations of X as possible.
 social
engineering
 bribe
or trick the security personnel
© 2000 Franz Kurfess
Security 40
Intruders
 persons
from outside seek unauthorized access to a
computer system
 frequently
via network connection
 intruders are often referred to as hackers or crackers
 legitimate
users make unauthorized use of a system
 evasion of auditing or access controls
© 2000 Franz Kurfess
Security 41
Program and System Threats
 Trapdoors
 Logic
Bombs
 Trojan Horses
 Viruses
 Bacteria
 Worms
© 2000 Franz Kurfess
Security 42
Taxonomy of Software Threats
Malicious
Programs
Needs Host
Program
Trap
Door
Logic
Bomb
Trojan
Horse
Independent
Virus
Bacterium
Worm
replicate
© 2000 Franz Kurfess
[Bowles and Pelaez, 1992]
Security 43
Trap Door
 hidden
 often

left by the designer of a program
for debugging or malicious purposes
 can
 can
entry point to the system
circumvent normal security procedures
be very difficult to detect
© 2000 Franz Kurfess
Security 44
Example Trap Door
 an
employee of a bank works on the transaction
processing system used by the bank
 to be prepared for unpleasant situations at work, she
leaves an entry point into the system
 she’s fired for security violations
 after she’s fired, she gains access via modem,
transfers a large amount of money to an account on
a Caribbean island, and erases all files
© 2000 Franz Kurfess
Security 45
Confinement Example
 you’re
a great physicist working on a novel approach to
the unified theory of everything
 unfortunately, your programming skills are not sufficient,
and you have to trust programmers

they know only the code, but not some critical values that you
enter interactively
 you
inspect their programs, compile and install them
yourself to make sure that there is no communication
outside your own account
 you perform all your simulations and calculations
 you’re ready to publish your results when you see an
article written by your programmers with your results
© 2000 Franz Kurfess
Security 46
Confinement Problem
 can
programs be written in such a way that the
information used and generated cannot be
communicated outside the domain?
 no
network connection
 no writing to files outside the domain
 no usage of peripheral devices
 problem:
covert channels
 information
can be transmitted through indirect ways
 relies on properties of the process execution that can be
observed by other processes

length of CPU bursts, paging rate, etc.
© 2000 Franz Kurfess
Security 47
Logic Bombs
 segment
in a regular program that checks for certain
conditions
 when the conditions are met, some unwanted
functions are executed
© 2000 Franz Kurfess
Security 48
Example Logic Bomb
a
contractor implements a logic bomb in a library
circulation system
 the bomb is designed to go off on a certain date
unless the contractor had been paid
© 2000 Franz Kurfess
Security 49
Trojan Horses
 (seemingly)
useful program containing hidden code
that may perform unwanted functions
 hidden segment misuses its current environments
 runs
 often
in the user’s environment with all the user’s privileges
hidden in regular programs
 e.g.
login program, email, editor
© 2000 Franz Kurfess
Security 50
Examples Trojan Horse
 Example
1: True friends
 you’re
working on a programming assignment together
with your friend
 for testing purposes, you make your programs executable
for each other
 you invoke your friend’s program, and it deletes all your
files
 Example
2: Password Stealing
a
user writes a program that looks exactly like the login
procedure for a multi-user system
 it is left on the terminal for the next unsuspecting user
 this program reads the password and stores it
© 2000 Franz Kurfess
Security 51
Viruses
 fragment
of code embedded in a legitimate program
 designed to spread into other programs and
systems
 may be destructive or simply annoying
 display
of messages
 program malfunctions
 modification or deletion of files
 system crash
 most
prevalent on single-user systems
 weak
protection
 curiosity and negligence of users
© 2000 Franz Kurfess
Security 52
Virus Protection
 antivirus
programs
 practically
all current programs are effective only against
particular known viruses
 safe
computing
 purchase
only unopened media from reputable sources
 avoid shared media


floppy disks, bulletin boards
if you have to share media, apply antivirus programs immediately
© 2000 Franz Kurfess
Security 53
Bacteria
 programs
that consume system resources by
replicating themselves
 bacteria may reproduce exponentially, eventually
taking up all resources
© 2000 Franz Kurfess
Security 54
Worms
 programs
that replicate themselves and send copies
across network connections
 may perform unwanted functions in addition to
replication
© 2000 Franz Kurfess
Security 55
Internet Worm
 one
of the greatest computer security
violations of all times
 Robert Morris, Cornell University, first year
graduate student
 unleashed Nov. 2, 1988
 propagated to thousands of computers on the
Internet
 Sun
3 workstations and VAX computers running
Unix BSD 4.x
© 2000 Franz Kurfess
Security 56
Internet Worm cont.
 worm
components
 grappling
hook (99 lines of C code)
 the worm proper
 strategy
 compile
and execute the grappling hook on the machine
under attack
 upload main worm
 contact new hosts
 spread the grappling hook
© 2000 Franz Kurfess
Security 57
Worm Diagram
Grappling
Hook
Worm
Worm
worm sent
Infected System
© 2000 Franz Kurfess
Target System
Security 58
Internet Worm cont.
 transmission
methods to infect new machines:
 rsh
 finger
 sendmail
© 2000 Franz Kurfess
Security 59
Internet Worm cont.
 limited
replication
 on
an already infected machines new copies of the worm
would exit, except for every seventh instance
 caused
 may
a major disruption on affected systems
have been intended as harmless
© 2000 Franz Kurfess
Security 60
Remote Shell Flaw
 frequently
accessed remote hosts can be listed in a
file .xhosts
 remote
shells can be invoked without password
 the worm used these files to propagate to trusted
new hosts
© 2000 Franz Kurfess
Security 61
Finger Flaw
invoking finger with an argument that
exceeds the buffer of the finger demon
results in an overwrite of the stack frame
 the finger demon continued with the
execution of the argument instead of
returning to its main routine

© 2000 Franz Kurfess
Security 62
Sendmail Flaw
 the
debugging option of the sendmail program is
often left on as a background process
 intended
for testing purposes
 usually invoked with a user email address
 the
worm called debug with commands to mail and
execute a copy of the grappling hook
© 2000 Franz Kurfess
Security 63
The Worm’s Demise
 on
the evening of the next day countermeasures
were circulated to system administrators
 reasons for success
 quick
electronic communication
 access to source code
 distribution of source code and executables to remote
machines
 collaboration of experts
 Morris
was convicted in federal court ($10,000 fine,
3 years probation, 400 hours of community service,
legal fees)
© 2000 Franz Kurfess
Security 64
Countermeasures
 prevention
 possible

threats are anticipated
this is not possible for all threats
 mechanisms
are installed to prevent attacks
 detection
 in
case of an attack, it is identified and corrective
measures are taken
© 2000 Franz Kurfess
Security 65
Countermeasure Examples
 access
restrictions
 users
are only allowed to login from a specific terminal,
during certain days of the week, during certain hours of
the day.
 system
dials the user back at a predetermined
phone number
 login
 increase
login time to discourage repeated login tries
 record all logins
 traps
 easy
to break in accounts
seemingly
interesting information for intruders
© 2000
Franz
Kurfess
Security 66
Threat Monitoring
 limited
login attempts
 if
more than a few login attempts are unsuccessful, the
login process is aborted
 audit
log
 records
time, user, type of access to objects
 useful for recovery and prevention
 considerable overhead
 security
check
 systematic
checks for security holes
 usually done during low traffic times
© 2000 Franz Kurfess
Security 67
Security Checks
 periodic
 weak

exploration of potential security holes
passwords
short, easy to guess
 unauthorized
set-uid programs
 unauthorized programs in system directories
 suspicious processes

running time, behavior, access to resources
 improper

file and directory protections
user and system directories and files
 password file, device drivers, system programs
 modifications
© 2000 Franz Kurfess
to system programs
Security 68
Design Principles for Security
 system
 better
design should be public
verification and discovery of flaws
 minimum
privilege principle
 give
each process the least privilege possible
 default should be no access
 check
for authority and authentication
 simple, uniform protection mechanisms at low levels
 acceptable for users
© 2000 Franz Kurfess
Security 69
Encryption
 mainly
used for transmission and storage of
sensitive information
 e.g.
 basic
password file in Unix
mechanism
 information
is encrypted into an unintelligible format
 this is stored or transmitted
 the receiver or reader must decrypt it into readable format
 encryption
frequently relies on operations that can
be done efficiently in one direction, but the inverse
operation is very difficult to do
 e.g.
factorization of large integers
© 2000 Franz Kurfess
Security 70
Important Concepts and Terms














access control
access control list
audit log
authentication
capability list
confinement problem
deadlock
decryption
digital signature
encryption
external security
internal security
object
operation
© 2000 Franz Kurfess
 permission
 private
key cryptosystem
 privilege
 privileged instruction
 protection
 protection domain
 right
 security policy
 starvation
 subject
 system mode
 trojan horse
 user mode
 virus
Security 71
Chapter Summary
 physical
and operational safety of computer systems
can be important aspects
 protection methods and mechanisms are available
to prevent unauthorized access to and use of
computer systems
 especially networked computers are vulnerable to
security threats like
 trapdoors,
logic bombs, Trojan horses, viruses, bacteria,
worms
 the
main types of countermechanisms are
 prevention
© 2000 Franz Kurfess
and detection
Security 72