Operating System Security Erik Poll

Operating System Security
Erik Poll
About me
• Erik Poll, Security of Systems group (SoS),
Radboud University Nijmegen
• SoS group researches
– Software & Systems Security and Correctness
• esp. Java software, for smartcards, MIDP mobile
phones, and OS software
– Identity-centric Security & Privacy
• eg. electronic voting, biometric passports, RFID,
protocols for privacy & anonymity
• Industry & government cont(r)acts also via LaQuSo,
Laboratory for Quality Software (www.laquso.com) together
with TU/e
2
About you
• Who are you?
• What is your level of experience with - and
interests in - Operating Systems?
3
Objectives
• Understand the security aspects of and security
issues in Operating Systems (in a generic sense)
• You should be able to design / review security
plans for any Operating System by assessing
security functions from system or add-on
documentation
• Also, understand more general information security
principles
4
How
• Understand basics of Operating Systems
– NOT: a UNIX, Windows, or other OS course
• Understand how the OS interacts with hardware
– CPUs, memory, computer media, ..
– focus on security issues and measures
• Understand basics of OS security mechanisms
– will use some UNIX & Windows examples
– some OS-network security mechanisms e.g. authentication
– pointers to some of the current developments
• Technical issues, but also context & principles
5
Recommended reading on (OS) security
•
Bruce Schneier
– Secrets & Lies and Beyond Fear
– Crypto-gram newsletter
http://www.schneier.com/crypto-gram.html
•
Ross Anderson
– Security Engineering
Available online at
http://www.cl.cam.ac.uk/users/rja14/book.html
6
Practicalities
Your paper (1)
Why should the paper be read at all?
• Use this technique: start paper with max. 3-4 lines explaining
purpose, content and conclusion
The management summary of the management summary
• Have compassion with people
– e.g. Users understandably raised questions about GSMillnesses.
After careful study, this report concludes that there is no risk
and that management does not need to take additional
measures.
• Think: what would you like to see as headlines on the front
page of your newspaper about your paper?
• Think: if you were the receiver of the paper what would you
need ? Why would you put it on top of the stack rather than
8
in the dust-bin?
Your paper (2)
Intended audience?
• Your choice:
Ways to stop us reading (and obtaining a low grade)
• an annoying number of spelling errors & obviously not reread
after typing
• unstructured paper
• many unexplained abbreviations & jargon unknown to intended
audience
• unscreened, unjudged advertisement text
• not targeted to the target audience (e.g. discussion about
word 17, bit 5 status in support of an investment decision to
be taken...)
9
Example topics
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Single Sign-On Proposal & cryptogram Secure Login vs Windows 2000 Smart Card
Authentication
Hebben we de Pocket PC nog in de hand ?
Rule Set Based Access Control
Hardening Windows XP for usage in a Medical Workstation Environment
Onderzoek naar de bruikbaarheid van de Toshiba PC Card Fingerprint Reader voor
de beveiliging van laptops binnen de <Bedrijfsnaam>
Analyse van een gecompromitteerde UNIX host
Biometrie voor Defensie
Incident Response uit het oogpunt van de opsporing
WAP Identity Module
Een vergelijking tussen Digital’s VAX/VMS en Microsoft’s Windows NT/2000: Is
Windows NT/2000 een nieuw besturingssysteem?
SAP-SECURE Security design HPUX25, SAPP11, SAP11
Single Sign On in a global environment, business advantage or business risk?
Content protection using Java Card
A proposal for implementing a self-service kiosk to facilitate all non-IT workers in
accessing their personnel records and the initiation of changes in that data
Smartcard technologie in een Overheidsorganisatie
Hardening HP-UX 11.0: Maatregelen en uitvoering
EMV, Een Magisch Verhaal?
SECURITY FOR BANKING APPLICATIONS ON INTERNET
Evaluatie van de beveiligingsaspecten van smart cards met een RF interface
Een veilige lezer in een onveilige omgeving
10
Main outline
• History of Operating Systems
• What is an Operating System?
– Security & OS : CIAN, Trust, AAAA
• OS basics
– Process managament
– Memory management
– File management
• Authentication
– passwords as Achilles heel, TENEX
• Access control
– hardening
– reference monitors
– compartementalisation
• Trusted Computing, Ken Thomson
11
Main outline
• What is an Operating System?
– subparts, packaging, processes, booting
• Hardware
– Central Processing Unit (CPU)
– Storage
– Memory
• Basic functions
– scheduling of resources
– object access control & file systems
– authentication
• The wider context of operating security
12
The evolution of operating systems
History ..
14
Evolution of OSs: 40s & 50s
• No OS
• Programs run on the bare hardware
• Problem: all programs have to include the same code for
adressing peripherals
• Solution: library of device drivers, forming the first
primitive OS
15
Evolution of OSs: batch processing (60s)
Problem: expensive mainframe idle during set-up
Solution: batch monitor
– batch processing, with monitor getting jobs from disk and
monitoring them (starting & stopping jobs)
Inventions
• timer
• interrupt
• memory protection (for resident batch monitor)
• priviliged instruction (for resident batch monitor)
(As protection against errors & pranksters, not malicious
hackers)
16
Evolution of OSs: multi-tasking (60s)
Problem: expensive CPU idle during slow I/O
Solution: multi-programming aka multi-tasking
– multiple jobs, from different users, concurrently
– protection between jobs needed
Inventions
• memory management
• memory protection in hardware
(As protection against errors, not malicious hackers)
17
Evolution of OS: time-sharing (70s)
Problem: expensive personnel waiting for cheaper
computers
Solution: time-sharing
Inventions
• pre-emptive scheduling (for good response time)
• file systems
OS becomes very complicated
Example OSs: OS360, MULTICS, THE, and
UNIX (written in C!)
18
1970: security becomes an issue
W. Ware, Security Controls for Computer Systems: Report of Defense Science
Board Task Force on Computer Security, Rand Report R609-1 (Feb. 1970)
[http://seclab.cs.ucdavis.edu/projects/history/papers/ware70.pdf]
19
Evolution of OSs (80s)
Computers become cheap:
• Instead of multi-user mainframe, a PC for individual user
OS back to subroutine library: MS-DOS
• Minor security problems due to
viruses on floppy disks
20
Evolution of OS (90s)
Cheap computers become powerful.
OS becomes complicated again. (Re)introduction of
• multi-tasking
– but now to run multiple tasks for single user
• memory management
in PC world
• Possibilities of graphics allow introduction of graphical user
interface (GUI) to OS (Apple, Windows)
21
Evolution of OS (2000s)
• Networking!
• Lots of security problems!
– Security taken seriously by Microsoft
• OSs in simpler devices than PCs, eg PDAs, mobile
phones, and smartcards
• OS-like functionality in webbrowsers and in
computing plaforms, eg. Java and .NET
22
Slammer Worm (Jan 2002)
Pictures taken from The Spread of the Sapphire/Slammer Worm, by David Moore, Vern Paxson, Stefan Savage, Colleen Shannon, Stuart Staniford,
Nicholas Weaver
23
Slammer Worm (Jan 2002)
Pictures taken from The Spread of the Sapphire/Slammer Worm, by David Moore, Vern Paxson, Stefan Savage, Colleen Shannon, Stuart Staniford,
Nicholas Weaver
24
Historic developments
• Operating systems evolve over time with “CPU power”
– the “old” mainframe concepts are now in your PC or handheld
and the even older ones are in embedded processes &
smartcards
• Operating systems
– OS/360, NOS/BE, COS, …
– Multics  Unix  BSD and System V lines (HP.UX, AIX, ..)
 Linux, ..
– DoS  Windows’95  Windows 2000, XP, Windows 2003, ..
– Palm OS, Windows CE, EPOC, Symbian, ...
– operating systems in telephone exchanges
– OS in network components (Cisco IOS, ...)
25
Migration of OS concepts & features
Twins
Over time, complexity & expensiveness of today's main
systems moves to wearable embedded systems
26
Future of OS
• Realtime for audio & video (performance!)
• More networking (internet, mobile phones)
– more security problems
– network computer, without file system
• More multi-processor machines, to keep up
Moore's Law
• Operating systems in ever more devices (incl.
embedded systems), eg PDAs, phones, smartcards,
cars, ...
27
What is an operating system?
What is an operating system (OS)?
• A program that acts as an intermediary between a
user of a computer and the computer hardware
• A program that manages all the other programs
and basic tasks in a (computer) system, and
manages all the resources of the system
29
What is an OS ?
Two viewpoints:
• virtual machine offering a library (API) of systems
calls as interface to underlying hardware
– abstraction of underlying details
• for simplicity, but also for security
– portability, esp. if library is standardised (eg Win32API,
POSIX)
• resource manager for efficient & secure
management of shared resources
30
Operating System
• Intermediary between the hardware and the users
– allocates resources between programs and users fairly and
efficiently
– protects the system from incorrect or malicious programs
(and users)
– protects separate user spaces
– allows the user to conveniently access data, programs and
other resources
– executes user programs
– optimises the total efficiency of the system
– manages input and output devices
- ...
• from system start-up until system shutdown
31
Resources controlled and protected by OS
•
•
•
•
•
•
•
•
CPU (process management)
Memory (memory management)
Timers
Storage on disks (file systems)
Terminals
Printers
Network
Bandwidth
32
OS as interface
sysadmin
user
application
program
Operating System (OS)
CPU
Memory
I/O
33
OS as interface
Users of the OS include
• sys-admins
• application developers/programmers
• users
• hackers
Border between OS and applications unclear
eg UNIX treats X-windows GUI as utility, but Win32API
includes GUI
34
Background:
Information Security
Security Objectives: CIA
• Confidentiality (or secrecy)
– unauthorised users cannot read information
• Integrity
– unauthorised users cannot alter information
• Avaliability
– authorised users can access information
• Non-repudiation for accountability
– authorised users cannot deny actions
36
Security objectives
• Integrity nearly always more important than
confidentiality
Eg think of
– your bank account information
– your medical records
– the entire operating system, and all data on a file system,
esp. after a break in
• Privacy special case of confidentialy, namely for
personal data
37
Availability – related concepts
• Reliability
– How often does system fail ?
– What is the percentage of uptime?
• Resilience
– How resistant is the system to failure of components
– How quickly can the systems recover/be restarted in the
event of failure
• Performance
– How does system cope with excessive load?
– Esp. relevant for Denial-of-Service attacks
38
Trust
• Beware of the use of "trust" or "trusted".
– If a system is trusted, is that a good or a bad thing?
• NB trusted ≠ trustworthy
• Trusted Computing Base (TCB) is that part of the
system that we have to rely on for security
– ie that part of the sytem where bugs can result in
insecurity
• The TCB should be
– as small as possible
– as trustworthy as possible
• Typically, the OS (or at least a large part of it) is
in the TCB
39
How to realise security objectives? AAAA
• Authentication
– who are you?
• Access control/Authorisation
– control who is allowed to do what
– this requires a specification of who is allowed to do what
• Auditing
– check if anything went wrong
• Action
– if so, take action
40
How to realise secuity objectives?
Other names for the last three A's
• Prevention
– measures to stop breaches of security goals
• Detection
– measures to detect breaches of security goals
• Reaction
– measures to recover assets, repair damage, and persecute
(and deter) offenders
NB don't be tempted into thinking that good
prevention makes detection & reaction superflous.
Eg. breaking into any house with windows is trivial; despite this
absence of prevention, detection & reaction still deter burglars.
41
Note parallels with security in physical world
• Who do you let into your house?
• What are they allowed to do in your house? With/without
supervision?
• Periodically check for broken windows, forced doors, missing
dvd records, ...
• If so: call the policy, call the insurance, buy better locks, ...
but also the differences
42
Example information security strategies
Prevention
Detection
Reaction
Societal
Organisational
Network
Operating
System
Hardware
43
Example information security strategies
Prevention
Detection
Societal
Reaction
Policing,
Legislation
Organisational Security policies, eg
Computer
Emergency
Response Team
Network
Firewalls, Encryption
Intrusion detection
Operating
System
Authentication
Authorisation
(Access Control)
Virus detection
Logging & Audit
Hardware
Memory management,
kernel/user mode
password policy,
physical security,
hardware redundancy
Backup &
restore
44
Security principles:
ie general dos and don'ts
•
•
•
•
•
•
•
See
secure the weakest link
defence in depth
principle of least
privilige
minimise attack surface
compartementalise
secure defaults
keep it simple (KISS)
•
fail securely
• promote privacy
• hiding secrets is hard
• use community resources
(ie google is your friend!)
• be reluctant to trust
• identify your
assumptions
https://buildsecurityin.us-cert.gov/daisy/bsi/articles/knowledge/principles.html
• ...
45
Security principles
These principles can be applied at many levels, eg.
• within a single application
• between applications
• at OS level
• at network level
• within an organisation
• between organisations
• ...
46
Fundamental OS security issues
• How do we control which people can use a
computer system?
• How do control which programs a user can run?
• How do we control which resources a process can
access?
• How do we protect processes that share computer
resources from each other?
We'll start with this last question
47
Security measures offered by OS
• abstraction in interface to underlying hardware
– hiding lower level details prevents access to & abuse of these
details
– but abstraction layers may be circumvented...
• kernel vs user mode
• notion of process
– scheduling controls access to CPU
– PCB control access to memory, files, ...
• virtual memory
– controls access to memory
• file systems
• authentication
• access control/autorisation
48
Process management
Processes
A process is
• a program in execution
• a sequence of instructions executed in a certain
context, aka an execution trace
NB process ≠ program
eg there can two processes executing the same
program simultaneously
Process is executed by the CPU.
Without CPU there can be no processes.
50
Processes
• The notion of process is the central abstraction in
the OS
– Everything that happens on a computer is part of some process,
and everything the user interacts with is a process
– A modern OS is a collection of processes
• Central idea: processes are independent, and
cannot directly influence each other
– The OS allocates resources to each individual process, eg
CPU time and memory
– Hence each process has its own memory, ie. part of the
RAM for its exclusive use
– Access control is organised around processes – more on
that later
51
Processes
Two views of a process
• a process is a unit of dispatch, ie. something that
can be executed
• a process is a collection of resources
52
Processes
A process requires a piece of memory in RAM, for
• program code
• data
• an execution stack, that records the outstanding
subroutines and their arguments
When a process is executing on the CPU, the
program counter (PC) will point to the instruction
in its program code
53
Multi-programming
• Uni-programming: only one process is active
– eg MS-DOS
• Multi-programming (or multi-tasking): many
processes active at the same time
– eg any modern OS: UNIX, Windows, Linux
One single processor machine, multi-programming
gives the illusion of multiple CPUs, by time-sharing.
54
Why multi-programming?
• efficient use of CPU during slow I/O
– despite overhead of context switches
• user wants it
– eg to check email while making powerpoint slides
• useful in organisation of programs (incl. OS)
– eg daemons
• lowering response times
– esp. responsiveness of user interface
• to use multiple CPUs on multiprocessor machine
55
Multi-programming for efficient CPU use
uni-processing – cpu idle during long I/O
cpu active
i/o operation
i/o operation
time
multi-processing – cpu active during I/O
process 1 cpu active
process 2
i/o operation
cpu active
i/o operation
i/o operation
i/o operation
process/contex switches
56
Multi-programming for efficient CPU use
• Note the extreme differences in speed between
CPU and peripheral devices (incl. human users)
• Typical CPU is now faster 1GHz.
How long is 1 Giga-second ?
57
Context switching
Process switching causes some overhead:
• It takes some time
• It requires some administration by the OS:
– the OS has to maintain a snapshot of the CPU state for
every process in memory
• ie the value of the Process Counter (PC) and all the
other registers
• It requires hardware support
– to store the CPU state to memory, or load the CPU state
from memory
58
Process administration
• Every process has a unique process ID (PID)
• The OS maintains info about each process is a
Process Contol Block (PCB), incl
which program code it is executing
which memory has been allocated to it
value of program counter (pc) of that process
value of registers for that process
execution stack for that process (which records
outstanding subroutine calls and local parameters)
– other resources allocated to that process, eg which files
have been opened for reading or writing
–
–
–
–
–
59
Process states
A process has a state, which can be
• running – if the process is using the CPU
• ready – if it could use the CPU when it becomes
available
• blocked – if the process is waiting for some
external event, typicallly completion of I/O
The OS maintains a ready list of all the processes
that are ready to run, and gives these processes
turns at using the CPU.
60
Process state transitions
• When the CPU becomes available, it is given to the
first ready process in the ready list
– the registers of the CPU are then loaded with the
information about that proces
– its state changes from ready to running
– the process is allocated a certain amount time to use the
CPU, called a quantum
61
Process state transitions
• When the quantum expires, the CPU is taken away
from the process:
– it state changes back from running to ready,
– it joins the back of the ready queue, and
– the next process in the ready list is given the CPU
• If a process ends or blocks for I/O before its
quantum expires, the CPU also becomes available
and is given to the next process in the ready list
62
Process state transitions
–
(trap)
died
63
Process scheduling
• There are many scheduling algorithms for deciding
in which order processes get the CPU and for how
long.
• Certain processes will be given higher priority,
reaching the head of the ready list more quickly
than others.
– Possible reasons for higher priority
• important system task that need priority
• efficient use of resources
• real-time constraints
• It is important that no process dies because of
CPU starvation.
64
Multi-processing & security
Multi-processing introduces security threats.
A buggy or malicious program could
• write to memory of another process
• write to memory used by the OS,
– eg the ready list used by the scheduler, or its quantum
• use up too much resources (CPU time, memory, disk
space, PIDs, ... ), constituting a DoS attack
Processes have to be protected from each other, and
constrainted not to use too much resources
65
Execution modes/privilege levels
• Most OSs distinguish different execution modes
or privilege levels:
– kernel mode (aka supervisor or system mode)
– user mode
• Kernel mode gives certain priviliges:
– full access to the whole memory, and
– all instructions supported by the CPU
• some instructions cannot be executed in user mode
• The goal is to protect the system from application
bugs and malicious software.
• The kernel is that part of the OS that runs in
kernel model
66
Modes in hardware
Execution modes must be supported in hardware.
The Pentium processor supports 4 execution modes.
Windows and Linux use only 2 of these
• level 0 (higest priority) for kernel mode
• level 3 (lowest priority) for user mode
67
Mode switches for system calls
• When a user process performs a system call,
invoking some OS functionality, a mode switch
occurs:
– the process is switched to kernel mode for the executes
the system call
– when returning from the system call, the process is
returned to user mode
– In most OSs processes have two stacks, a user level stack
and a kernel level stack.
68
• Code that is executed in kernel mode is trusted.
– NB trust is a negative quality. If something is trusted, it
can do you harm. In trusted software, bugs can cause
serious problems.
• By the principle of least privilige, kernel mode
should only be used when strictly necessary.
69
• Two problems limit the effectiveness of the idea
of kernel vs user mode to protect the system:
– buffer overflow vulnerabitilities in system calls
allow malicious user code to execute arbitrary
code in kernel mode
• more on buffer overflows later
– kernel bloat: ideally,only a small part of the OS
code should run in kernel mode, but for most
OSs the size of the kernel can be huge.
70
Threads
Threads
• One motivation for having multiple processes is
organisation: to organise a task, it can be
convenient to split it in several tasks
• For this reason it can also be useful to split a
single application in multiple concurrent tasks:
these are called threads
72
Threads vs processes
• Within a process, threads execute independently,
but sharing resources, eg memory, program code,
files, ...
– Thread is a unit of dispatching
– Process is an owner of resources
– Modern OSs are beginning to allow access control on a per
thread basis
73
Pros & cons of threads
pros
• organisation
• efficient use of resources
• responsiveness of application
• taking advantage of multiple-processor capabilities
cons
• complexity, possibly resulting in bugs, eg
– data races
– deadlocks
74
Aside on multi-processor machines
• Multi-processor machines offer the advantage of extra
speed, but until recently, multi-processor machines were not
so common: speeds of microprocessors were increasing so
rapidly, by Moore's Law, that the added complexity of multiprocessors did not outweigh the extra computing power.
• An interesting article predicting the rise of multi-processor
machines and associated problems in multi-threaded code
that uses its capabilities is "The free lunch is over" by Herb
Sutter.
75
Memory management
Memory management
• The OS is responsible for allocating memory to
processes in a fair way.
• For security, the OS should guarantee memory
protection: processes should not be able to access
memory of other processes, or the OS
77
Old-fashioned memory management
• OS partitions memory in parts (segments), one for
each process, and one for OS itself
• For every memory access by a process, it is
checked if it respects its memory bounds
– These checks should be in hardware! Why?
• Lots of possibilities for partitioning
– fixed or variable sized parts?
– changing partioning in life-time of process?
– goal: minimizing fragmentation
78
Memory partioning
• Registers for separation
user job spaces
• Kernel / monitor takes all
OS kernel
Base =0
Limit= 1023777
• OS keeps track of
unallocated memory
– may relocate jobs
– block move +
change relocation register
79
Memory protection in hardware
physical
+
0 .. limit-1
• current base and limit in CPU registers, and recorded for all processes in PCBs
• addressing error results in application crash due to segmentation fault
80
Swapping
Moving process from memory to disk
– ie from primary to secondary memory
Goals
• free primary memory
• reduce system load
81
Paging
• Physical memory divided into fixed-sized blocks:
frames
• Logical memory of process divided into blocks of
the same size: pages
• Pages assigned to frames, in any order, with
mapping of pages to frames recorded in page table
• Logical addresses used by the CPU divided into
– page number (p)
• used as an index into page table, giving frame number
– page offset (d)
• which gives the offset in that frame
82
Virtual address translation architecture
offset d
page p
frame f
83
Paging
• Translation of virtual/logical addresses to physical
addresses ensures that process cannot address
memory of other process
– memory protection `for free'
• Each memory access takes two memory accesses:
one to read page table, one for actual access
– To mitigate this slowness:
• TLB (Transition Look-aside Buffer), caches
84
Example
Frame 1
Page 2
Page size = 4
frame# *page size= physical address
Page 3 can be found at frame 2
or base address 2*4 = 8 with
limit = 8+(pagesize-1)
85
Paging hardware with
translation look-aside buffer (TLB)
CPU
hardware
- Fast if TLB hit
- Hardware keeps track
of least recently used
- Insert last used p-f
combination in TLB
replacing LRU-entry
“associative
page memory”
In main
memory
86
Virtual memory
• Swapping in combination with paging :
Not all the pages of a process need to be in RAM.
Some can be on disk
– In the event of a page fault, a memory access might
require a (slow!) disk access, to retrieve page from disk
• Virtual address space of a process can now be
much larger than physical memory
– address space limited by hardware:
• 32 bits architecture gives 232 virtual addresses per process
• Introduces the danger of thrashing if system spends all its
time handling page faults under heavy load
87
Insecurities in memory management
• Memory protection ensures that processes can not
read - or worse, write - to each other's memory.
• But memory protection does not prevent access to
the memory of a process after it is released.
– memory is not zeroed out by the OS upon allocation or
deallocation
• Malicious users or processes can look for sensitive
data in fresh memory allocated to them.
Security Principle: It is hard to keep secrets.
88
Sun tarball problem (1993)
• Every tarball (zip-file) produced on Solaris 2.0 contained
fragments of the password file /etc/password
• How did this happen?
– tar looked up some user info directly prior to producing tarball:
• password file was loaded in heap memory for this
• this heap memory was then released
– then tar allocated memory for constructing the tarball
• allocated memory was always the memory just released
• memory not zeroed out on allocation by program or OS...
• Solution: replacing char *buf (char*)malloc(BUFSIZE)
by char *buf (char*)calloc(BUFSIZE)
89
More insecurities in memory management
Swapping introduces another insecurity
• The disk will contain memory pages of processes,
even after you switch of your computer
– RAM is transient memory, but disk is persistent
– Disk space is not zeroed out upon swapping of pages
• Countermeasure: locking pages in memory to prevent them
being swapped
Security Principle: It is hard to keep secrets.
90
File systems
File system as abstraction layer
• File system provides an abstraction (of files and
directories) of persistent storage
– RAM is transient, hard disk is persistent storage
• Main persistent storage media is hard disk, but
there are others: CD, DVD, USB sticks...
• Persistence is good for security
– esp. ensuring availability
and bad for security
– esp. ensuring confidentiality
92
File system as basis for access control
• This abstraction layer is used to the basis for
access control,
– ie control who has the right to access (read, write, create,
delete, ...) which files and directories
– More on access control later.
93
File system as abstraction layer
• File system is also used as abstraction layer for
other I/O devices
– keyboard, screen, ...
• This is possible, because
– input device such as keyboard can be treated as file that can
only be read from
– output device such as terminal window can be treated as file
that can only be written to
• This makes sense for reasons of uniformity & simplicity
– same system calls can be used for lots of devices
– same access control mechanism can be used
94
File system as abstraction layer
•
•
•
A modern OS provides gui to the file system
– This interface presents a logical/virtual view of the file system,
with files in a hierarchical directory structure
– This abstracts from the physical/concrete organisation of the
file, as bytes in different regions of the hard disk
This abstraction is not just useful for the user, but it is also
crucial for security
– Only OS can access the physical disk. A user only sees the
logical view, and can only ask the OS to access the physical disk
for her.
Breaking/circumventing abstraction layers is a standard way of
breaking security.
– How would you do this for file system?
– Is this also possible for memory?
95
Typical security incidents with persistent storage
• People putting old PC in garbage
• People loosing USB sticks or floppy disks
96
97
Insecurity of file systems
• The abstraction and associated access control to disk
provided by the OS can be by-passed, by removing the hard
disk
• Countermeasure: encrypted file system
– New risk: loosing the key!
• Cryptography can solve some security problems, but it always
introduces a new one, namely key management
• The access control to memory of the OS is harder to by-pass
– but not impossible...
98
Insecurity of file systems
• Where is your (deleted) data and are your actions?
–
–
–
–
–
–
–
–
delete is in most OS file systems not a delete
journaling, transaction logs, recycle bin
caches
swap or page file
old data left in file system blocks on disk
unassigned and flagged ‘damaged’ sectors
why use your OS and not another one for mounting?
special hardware allows read, even after n wipes
• Security requires old & defective media policy
99
Insecurity of file systems
• New or changing circumstances cause new security problems
– new technologies
– new applications of existing technologies: function creep
• Examples
–
–
–
–
laptops
people working on a PC at home instead of the office, and vv.
removable persistent mass storage: USB sticks, iPods,....
wireless connections
• to connect computer to wireless network
• to connect peripherals to computer (keyboard, mouse,
headset,....)
Security principle: identify your assumptions
100
Access control
Fundamental OS security issues
• How do we protect processes that share computer
resources from each other?
• How do we control which resources a process can
access?
OS security measures: notion of process, kernel/user
mode, memory protection, abstractions in file system, ...
• How do we control which people can use a
computer system?
• How do control which programs a user can run?
This requires access control.
A first step for access control is authentication
102
Authentication
Authentication
• Authentication is the process by which we identify
authorised users of a system
• Access control (or authorisation) assumes the
existence of some form of authentication
• “Without identifying and authenticating the user logging on to the
•
system, access to objects cannot be controlled, user rights and
abilities cannot be enforced, and accountability cannot be
maintained via auditing. For these reasons Windows 95 and
Windows 98 can never be considered secure operating systems.”
– Windows 2000 Security Technical Reference
Mandatory log on is a fundamental security requirement
– Part of the C2 requirements of the US Trusted Computer
Security Evaluation Criteria (TCSEC)
104
Authentication methods
Something you have, are, or know
Eg
– key
– face, voice, fingerprint, iris
– signature, password
or a combination of these
– eg passport + face, smartcard +PIN
105
Authentication methods
• Most common form of authentication for computer
systems is for user to enter a username and login
• Alternatives that are eg. supported in Windows 2000
– biometrics
– smartcards
106
Problems with passwords (1)
They are easy to guess
• This enables brute force/dictionary attacks
Countermeasures:
• limit number of login attempts
– but this creates possibilities for a DoS attack!
• better: slow down login attempts
• improve quality of passwords
–
–
–
–
educate users
enforce a password policy
provide feedback on quality of password
periodically run password cracker to detect weak passwords
107
Example (good&bad!) password policy
• Het wachtwoord moet bestaan uit minimaal 8 en
maximaal 10 karakters.
Letters: a t/m z en A t/m Z
Cijfers: 0 t/m 9
Tekens: ! % * ( ) _ + - = { } [ ] | \ < > /
• Het moet tenminste één letter, één cijfer en één teken
bevatten.
• Inlogcode en RU-wachtwoord mogen niet hetzelfde zijn.
• Het wachtwoord moet minstens één maal per jaar worden
veranderd.
• Een nieuw wachtwoord mag niet hetzelfde zijn als de drie
wachtwoorden die daarvoor zijn gebruikt. [ Source http://www.ru.nl/idm/wachtwoord_wijzigen/wachtwoord_policy]
108
Problems with passwords (2):
They are not kept secret
• Told to others, written down
– NB writing down passwords not always bad!
• Inserted in scripts, configuration files, password managers,
given as input to untrustworthy applications
• Send unencrypted over the web
• Obtained by social engineering tricks, eg
– phishing
– phoning sysadmin
Also think of a good lost password policy
Security Principle: secure the weakest link
• stored in password file...
109
Password storage
Plaintext password file:
• ie passwords stored “in the clear” as (uid, pwd)
• strong access control of password file crucial!
• root user can obtain all passwords, and try these out on other
systems ...
• but access control of hard disk can be by-passed ...
• and what about backup tapes ...
110
Password storage
Hashed password file:
• ie passwords hashed (with secure hash), so password file
contains (uid,hash(pwd))
• At login, the entered password is hashed and compared with
the hashed password in password file
• Password never unecrypted on hard disk and only briefly
unencrypted in main memory
• Even root, of hacker with access to password file, cannot
read passwords
• Better still: store (uid,hash1000(pwd)) in password file
111
Secure hash
• A secure hash is a function f for which it is difficult – ie.
time-consuming - to compute the inverse f-1
– Ie given y, it is difficult to find an x such that f(x)=y
• The only way to do this is to try all possible values of x
• If x is eg a 256 bit word is, this is not (yet!) computationally
feasible
112
Hashed password file
•
Suppose you have access to a hashed password file.
How do you find out password ?
•
Dictionary attack: hash likely passwords and compare to
hasehed value in the file
–
–
Eg all alphanumeric strings with length < 6
NB 366 is much smaller than 2256 !
113
Salted hashed password file
Protection against dictionary attack: salt
•
Instead of
(uid, hash(pwd))
store
(uid, hash(pwd,salt))
in password file, with salt some known value that is
different for every entry (eg the uid itself)
•
•
How does this protect against dictionary attacks?
Also, different logins with the same password are no
longer obvious from the password file.
114
Information leakage & covert channels
• Famous security flaw in password checking on TENEX OS in
1970s.
– Password comparison character by character, aborted on first
wrong character
– Attackers timed how fast a password was rejected
• by having part of the password swapped to disk
– This revealed if first character was correct
– Repeating this procedure for other characters
• Here the response time is a hidden channel aka covert
channel aka side channel that leaks information
– in this case about the password
115
Information leakage & covert channels
Other covert channels during authentication
• login mechanism that identifies the OS as Linux Redhat 8.0
before login
– similary: webpage publishing error message of underlying
VBScript, SQL database,...
• login mechanism revealing the difference between nonexistent username and incorrect password after failed login
attempt
• login mechanism logging both the username & (incorrect)
password on failed login attempt
116
Alternatives for passwords
• One-time passwords
• Smartcards
• Biometrics
– Hot topic, but not without limits or disadvantages!
• If we do not trust the communication channel
between user & system:
– Challenge response systems:
• eg e-Identier for internet banking
– Second secure channel, eg one-time password via SMS
• .....
117
Authentication: challenge - response
Terminal side
System side
ID (e.g userID)
Look-up ID
Generate challenge
e.g. hashed time
Encrypt challenge with pin,
knowledge or token as key
Encrypt
stored key
OK or FAIL
118
Authentication with Third Party
Kerberos, Trusted Third Party, Single sign-on
Login xyz
If authentication ok
Background process (hidden to
user)
119
Mutual authentication
• So far, we discussed the computer system authenticating the
user.
• But shouldn't the user also authenticate the computer
system?
• Ctrl-Alt-Del keystroke sequence providing a trusted path to
the OS in Windows
• For login over network: use certificates or public-key crypto
– as used for authenticating websites
– NB users notoriously sloppy with accepting certificates or
changes in private keys
Security principle: be reluctant to trust
120
"Humans are incapable of securely storing highquality cryptographic keys, and they have
unacceptable speed and accuracy when performing
cryptographic operations. They are also large,
expensive to maintain, difficult to manage, and
they pollute the environment. It is astonishing
that these devices continue to be manufactured
and deployed. But they are sufficently pervasive
that we must design our protocols around their
limitations"
– Kaufman, Perlman, and Speciner
121
Further reading
• Lots of (fun) material on passwords and social engineering in
Secrets and Lies (Bruce Schneier) or Security Engineering
(Ross Anderson)
• Chapter on Passwords in 19 Deadly Sins of Software Security
by M. Howard, D. LeBlanc, J. Viega.
•
A Guide to Understanding Identification and Authentication in
Trusted Systems
– http://www.radium.ncsc.mil/tpep/library/rainbow/NCSC-TG-017.pdf
•
US Department of Defense Password Management Guideline
– http://www.radium.ncsc.mil/tpep/library/rainbow/CSC-STD-002-85.pdf
122
Access control
Access control: introduction
• Security = regulating access to assets, ie.
information or services
• Two important cases:
– An attacker has access to the raw bits representing the
information
=> need for cryptographic techniques
– There is a software layer between the attacker and the
information/services
=> access control techniques
124
Access control vs cryptography
• crypto involves data
• access control involves
functionality
• crypto can prevent people
from reading a (encrypted)
file, by making this
impossible unless they have
the right key
• access control can prevents
people from reading a file,
by denying them to open it
unless they have permission
• crypto can (also) regulate
access to data that are not
under our control, eg data
on network
• access control can only
regulate for access to
resources under our control
125
"Using encryption on the Internet is the
equivalent of arranging an armored car to deliver
credit card information from someone living in a
cardboard box to someone living on a park bench."
-- Gene Spafford
126
Access control
After authentication has taken place,
access control (or authorisation) involves
• specification of access rights
– who is allowed to do what to whom
• enforcing of access rights
– ie checks directly prior to every action
• auditing
– ie logging & checking the logs afterwards
Access control not only in OS, but also in applications or
databases.
127
Access control matrix
•
Conceptually, access control involves a matrix, telling which
subject (or principal) is allowed to do what (read, write,
create, destroy, execute) to which object
matrix ⊆ Subjects x Operations x Objects
•
Example: OS access control matrix in UNIX
file1
file2
file3
root
rw
rw
rwx
user1
-
-
x
user2
r
rw
x
128
Access control matrix
The central, practical challenge:
how do we manage the huge matrix we need?
How can we accurately describe what we want, given its huge size
& complexity ?
Solutions:
• organisation by row or column:
– Access Control List (ACL): say for each object who can do
what to it. Most common.
– Capability List: say for each user/proces what (s)he can
access.
• collecting subjects into groups or roles
129
Access control policy & model
• Access control policy = rules that say what is
allowed and what not
• Access control model = formalism to write down
the policy
– Different access control models exist to accommodate
different policies
– Model should be simple, expressive, intuitive, manageable,
implementable,…
130
Terminology
• Object: passive entity (piece of information)
requiring controlled access (e.g. file)
• Access operations: ways to access objects
• Users start sessions/subjects on computer that
will access objects using operations.
• Sessions with the same permissions are grouped in
protection domains
• The policy says what permissions each protection
domain has
• The reference monitor enforces the policy on each
attempted object access
131
System Model
Protection domains
S1
Users
S3
S2
Reference
monitor
Policy:
permissions for
each protection
domain
O1
S4
operations
S5
S6
O2
O3
O4
Subjects/sessions
Objects
132
• Policy describes the access control matrix
– in what is hopefully a convenient way
• The reference monitor is part of the kernel, and
may also do logging, in addition to granting/denying
• The reference monitor is part of the Trusted
Computing Base (TCB)
133
Formal access control models
• Bell-Lapuda
– for ensuring confidentiality
• Biba
– dual to Bell-Lapuda, for ensuring integrity
• Chinese Wall
– for preventing conflicts of interest
• Clark-Wilson
– for integrity; more for application-level security than OS
• Role-Based Access Control
– extension of Clark-Wilson
– can be mimicked in OS using groups
134
Access control in OS
• Access control in OSs is a lot more messy than these models.
– formal access control models on previous slide can provide some
background, but do not give whole picture of OS access control!
• Different forms of access control in OS include
– Discretionary Access Control (DAC)
– Mandatory Access Control (MAC)
– Multi-level Security (MLS)
• often in combination with MAC
– Role-based Access Control (RBAC)
• usually as variant of DAC
135
Discretionary Access Control (DAC)
• Every object has an owner
• Owner has full discretion to granting access rights
to an object to others
– ie no restrictions on which access rights the owner grants
to others
• This is what traditional modern OSs offer
136
Discretionary Access Control in UNIX
• User has user-id and group-id
• File has owner and group, and rwx-permissions for
owner, group, other
•
rw-r--r-- erikpoll sos exam.tex
137
DAC
Disadvantages:
• Cumbersome administration
– E.g user leaving the company or user being promoted to
another function in the company
• Not so secure:
– Social engineering
• because user is in charge of granting right to files
– Trojan horse problem
• malicious program started by user can do anything that the
user can do
138
DAC Extensions
• Structuring users to make administration easier
– Groups
• eg owner/group/other distinction in UNIX
– Roles
• Role-based access control
– Negative permissions
But: insufficient to make administration much
easier
139
Madatory Access Control (MAC)
• MAC provides a way to prevent the problem of
Tojan Horses
• Central idea: the owner of an object does not have
full discretion to granting access rights to that
object to others
There can be policies that restrict what an owner
is allowed to do
• Example
– normal user (as opposed to root/administator) cannot give
execute permission to objects
140
MAC and Multi-level Security
• The Bell-Lapuda model describes a combination of
MAC with Multi-Level Security, which can ensure
confidentiality.
• Interesting as example of power of MAC, not of
practical relevance to any modern OS.
• Multi-level Security (MLS) involves a lattice of
different security levels
141
Multi-level security
Objects classified by security levels organised in a lattice
Top secret
Secret
Confidential
Unclassified
Confidential
Project A & B
Confidential
Project A
Confidential
Project B
Unclassified
142
MAC + MLS solving the Trojan Horse problem
S1
S2
read
File F
no write down
Secret level
no read up
Unclassified level
write
File F’
143
MAC + MLS
Problems and disadvantages
• Aimed at DoD (Department of Defence)-like
applications, not well-suited for commercial
environments
– it addresses confidentialty, but not integrity
• Unworkable in practice
– More common solution: completely separate systems for
different security levels
• Covert channel problems
144
Multi-Level Security
• Multi-Level security is notoriously unworkable
– even in the intelligence community
• More realistic to use: compartmented security
– each department keeping information to itself, and
sharing information subject to clearly stated rules
145
Role-Based Access Control (RBAC)
• Introduces notion of role:
– many-to-many relation between users and permissions
– Corresponds to a well-defined job or responsibility
• When a user starts a session, he can activate some
or all of his roles
• A session has all the permissions associated with
the activated roles
146
RBAC - Extensions
• Hierarchical roles: senior role inherits all
permissions from junior role
Director of Eng Dept
Project A Eng
Project B Eng
Engineering Dept.
147
RBAC - Extensions
• Static constraints
– Constraints on the assignment of users to roles
– Eg. Static separation of duty: nobody can both:
• Order goods
• Approve payment
• Dynamic constraints
– Constraints on the simultaneous activation of roles
– Eg. to enforce principle of least privilege
148
RBAC in practice
• More managable than DAC
– but is it managable enough ?
• Implemented in databases
• Implemented in a generic way in middleware, eg
.NET
• Can be simulated in OS using "group" concepts
149
(Discretionary) Access Control in UNIX
• User has user-id and group-id
• File has owner and group, and rwx-permissions for
owner, group, other
•
rw-r--r-- erikpoll sos exam.tex
150
Access control in UNIX: umask
• Specifies the default access control on newly
created files & directories
• umask is a process environment (`shell') variable
151
Access control in UNIX: setuid
• A program (executable file) can be regarded as object and
subject
– who can access/execute the program (as object)?
– what can the program (as subject) access?
• Normally, process get the rights of the user starting it.
• setuid sets the user-id of the proces to be that of the
owner of the executable
– setuid process has the access rights of owner of the program
rather than the access rights of user starting the process
– Notorious source of security breaches
•
Newer UNIX & Linux systems provide finer-grained control using
capability tickets
152
Need for privileged functionality
• Setuid process allow users to temporary elevate their
privileges
• This may seem like a bad idea, but is unavoidable. Eg
– Any user can change her password; this requires write-access
to the password file.
– Logging in to a system requires read-access to the password
file, prior to any authentication
– Via www.cs.ru.nl/rooster anyone can query the database with.
– Note – this is similar to user code getting kernel model
priviliges for system calls.
• Such temporary elevation of privilege has security risk, and
bugs in these programs can be exploited
153
Access control in Windows 2000
• Every process has an access token, with
– User-id (SID)
– Groups-id's
– Default access control list, for objects created by this
process
• (cf. umask, but per process, not per user)
• Every object has a security descriptor, specifying
– which operations are allowed by which SIDs
– which operations are audited.
154
Access control in Windows 2000
• Finer-grained access control than UNIX
• But very complicated
– 30 different priviliges for operations
– 15 different kinds of objects
Meaning that even the professionals get it wrong...
•
For details, read eg. "Improving the Granularity of Access Control in
Windows 2000" by Swift et.al.
155
Getting access control wrong
Example of unintended privilige escalation in Windows XP
•
•
•
•
Instead of setuid, priviliged functionality in Windows XP
implemented as service, running under eg Local Service or Local
System account
Security descriptors "SERVICE_CHANGE_CONFIG .. grants
permission to change the executable associated with a service"
[Windows XP documention]
But it also allows to change the account under which it runs, incl to
the account Local System means the service runs with maximum
priliviges.
Many services mistakingly grant SERVICE_CHANGE_CONFIG to all
Authenticed Users...
[For more info, read "Windows Access Control Demystified" by S.
Govindavajhala and A.W. Appel]
156
Privilige escalation in Windows XP
Privilige escalations of software from different vendors
Source: "Windows Access Control Demystified" by S. Govindavajhala and A.W. Appel
157
SELinux
• Security Enhanced Linux is an extension of Linux
with MAC
• based on NSA research prototype, now in standard kernel
• improved confinement of processes (user programs and
system daemons) to reduce the damage that can be done
when their security is compromised (via buffer overflows or
misconfigurations, for example)
• No so easy to use...
158
Where does access control fail?
• Users unconsiously/implictly/stupidly giving permissions eg by
– (double) clicking on some email attachment
– downloading & executing software
OS may be partly is to blame for this.
• Users and sys-admins find access control cumbersome, and are
liberal with permissions, effectively switching access control
off
– typical examples: executing processes as root (super-user,
administrator), logging in as root to perform some tasks
Violating the security principle of least privilige
159
Where does access control fail?
In the specification, ie mistakes in the access control matrix.
Mistakes are common because, because
• access control is so complicated
– Note the fundamental conflict between
• principle of least privilige
– requires more fine-grained control => more complexity
• kiss principle – keep it simple
• access control that is too liberal is hard to notice,
– unlike access control that is too restrictive
– ie applying the principle of least privilige is hard!
160
Where does access control fail?
Many OSs ship with an insecure default configurations!
Countermeasure: harding the OS
• ie. rigorously applying the principle of least privilige
– disabling all functionality/services not needed
– restriction permissions on remaining services as much as possible
This situation should improve in the future.
161
Where does access control fail?
• Via software bugs, especially buffer overflows, in
– kernel code
– setuid programs
•
or any other code that gives the user temporarily more rights, eg.
cgi-bin scripts or SQL queries invoked over the internet via
webpages
162
Operating System insecurity:
Buffer Overflows
Buffer overflows (aka stack overflow)
• The number 1 cause of security problems.
• The main reason why systems need frequent
patching.
• The first Internet worm, and all subsequent ones
(CodeRed, Blaster, ...), exploited buffer overflows
• Buffer overflows cause in the order of 50% of all
security alerts
– Eg check out www.us-cert.gov/current, cve.mitre.org, or
bugtraq
• Buffer overflows are one example of the more gernal problem
of lack of input validation, which also includes SQL injection,
cross-site scripting,.....
164
What is a buffer overflow?
• Supplying a very long or very strange (incorrectly
formatted) input string to a program or system
call may crash it
– typically with segmentation fault
• If we then carefully construct the string, we may
be able to let the program do anything we want
– with the access right of that program
165
Essence of the problem
Suppose in a C program we have an array of length 4
char buffer[4];
What happens if we execute the statement below ?
buffer[5] = ‘a’;
Anything can happen !
If the data written (ie. the ‘a’) is user input that
can be controlled by an attacker, this vulnerability
can be exploited: anything that the attacker wants
can happen.
esp. if the program is kernel code.
166
Process memory layout
High
addresses
Arguments/ Environment
Stack
Stack grows
down,
by procedure
calls
Unused Memory
Heap (dynamic data)
Static Data
Low
addresses
Heap grows
up,
eg. by mallocs
Program Code
167
Stack-based buffer overflow
The stack consists of Activation Records:
x
AR main()
return address
AR f()
buf[4..7]
buf[0..3]
Stack grows
downwards
void f(int x) {
char[8] buf;
gets(buf);
}
void main() {
f(…); …
}
void launch_nukes(){…}
Buffer grows
upwards
168
Stack-based buffer overflow
What if gets() reads more than 8 bytes ?
x
AR main()
return address
AR f()
buf[4..7]
buf[0..3]
Stack grows
downwards
void f(int x) {
char[8] buf;
gets(buf);
}
void main() {
f(…); …
}
void launch_nukes(){…}
Buffer grows
upwards
169
Stack-based buffer overflow
What if gets() reads more than 8 bytes ?
x
AR main()
return address
AR f()
buf[4..7]
buf[0..3]
Stack grows
downwards
void f(int x) {
char[8] buf;
gets(buf);
}
void main() {
f(…); …
}
void launch_nukes(){…}
never use
gets()!
Buffer grows
upwards
170
Variants
• There are many other code-level defects, besides
overflowing a stack-allocated buffer, that can be
exploited:
–
–
–
–
–
–
Heap overflows
Dangling pointer bugs
Format string vulnerabilities
Integer overflows
Data races
…
171
Any C(++) or machine code acting
on untrusted input is at risk
Eg
• code taking input over untrusted network
– eg. sendmail, webbrowser, wireless network driver,...
• code taking input from untrusted user on multiuser system,
– esp. services running with high priviliges (as ROOT on
Unix/Linux, as SYSTEM on Windows)
• code acting on untrusted files
–
that have been downloaded or emailed
• also embedded software, eg. in devices with (wireless)
network connection such as mobile phones with Bluetooth,
wireless smartcards in new passport or OV card, airplane
navigation systems, ...
172
Solution to buffer overflow problem
• Check array bounds at runtime
– Algol 60 proposed this back in 1960!
• Unfortunately, C and C++ have not adopted this
solution, for efficiency reasons.
(Ada, Java, C#, and Visual Basic have adopted this.)
• As a result, buffer overflows have been the no 1
security problem in software ever since.
173
Mitigation of buffer overflow problem
• Improving software quality
• Reducing the attack surface
– NB on a typical OS the attack surface is so large, thatyou
should expect any determined user to be able to become
root/administrator
– Still, shutting down unneeded services helps
• Applying the principles of
– least privilige
– defence in depth
174
The attack surface
• In Windows and UNIX, most of the OS code and
all the code of device drivers is executed in kernel
mode.
• Consequently, TCB and the attack surface for
buffer overflow attacks are huge
– Many Windows vulnerabilities are due to bugs in third
party device drivers.
– Windows 2000 introduced the concept of driver signing to
protect users from malicious or buggy device drivers.
• Hopefully, we will see a trend towards micro-kernel OS
175
Kernel bloating
•
•
•
•
•
•
•
•
UNIX 1971
UNIX 1979
SunOS 4.1 1989
4.3 BSD 1991
HP UX 95. 1994
SunOS 5.6 1997
Linux 2.0 1998
Windows NT4.0 1999
33 system calls
47
171
136
163
190
229
3433
Source: Secrets and Lies, by Bruce Schneier
176
Trusted Computing
• Trusted Computing Group (TCG) alliance
– Microsoft, Intel, IBM, HP, AMD ...
promoting standard for a 'more secure' PC.
• Transfer of control from user to OS & software provider
• PC more trustworthy from the point of view of software
vendors and content industry, but from the point of view of
their owners?
• TC will not get rid of buffer overflows or other security
flaws in the OS or in applications!
[ More info http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html]
177
Other – or additional –
forms of access control
Untrusted code security,
Compartementalisation,
Virtualisation
Untrusted code security
• Traditional OSs offer some protection between
processes
process
process
A
B
but no protection within processes, so
- buggy device driver can make entire OS insecure
- buggy plug-in can make your web browser insecure
- buggy game on your mobile may make your phone insecure
(let alone malicious ones...)
179
Untrusted code security
• Modern computing platforms (Java en .NET) offer
access control inside applications
• Virtual Machine (VM) can checks access control,
not only of application as a whole but also per
component inside the application
• This sand-boxing is crucial for application using
mobile code, eg
• applets executing in your webbrowser
• Java midlets executing on your mobile phone
• JavaCard applets on your smartcard
• Access control inside applications only makes sense for typesafe languages which are not subject to buffer overflows
180
Untrusted code security
• OS performs access control of process P
• Java VM performs access control for (possibly less trusted)
extensions inside P
P
Internet
Code extension
Java VM
OS
Also: defence in depth
Resources
181
Code-based access control by Java sandbox
• Every class file is in protection domain based on
– where it was loaded from (URL)
– who signed it
• Permissions are rights to access resources or perform
operations
– eg FilePermission, SocketPermission, …
• Security policy gives permissions to protection domain
• Reference monitor is part of the Java platform called the
security manager
182
Compartementalisation
• Principle of least privilige works best if access
control is all or nothing for large chunks –
compartments - of a system
– ie coarse & simple access control with strong boundaries
• Motivations:
– simplicity (KISS principle)
– containing attacker in case of failure
• Analagy: compartments on a ship
• Counterexample: OS that crash if an application crashes
183
Compartementalisation examples
• Use different machines for different tasks
– eg run web application on a different machine than
employee salary database
– eg keep senstive data on a smartcard
• Use different user accounts on one machine for
different tasks
– but, unfortunately, security breach under one account may
compromise both...
– compartementalisation provided by typical OSs is poor!
• Compartment provided by Java sandbox
• Partition hard disk and install OS twice,
– eg once of office use and one for home use
184
Improved compartementalisation in UNIX
• chroot jail
restricts access of a process to subset of file
system,
– ie. changes the root of file system for that process
– eg. run an application you just downloaded with
chroot /home/sos/erikpoll/trial;/tmp
Nice & simple idea
though hard to get working with applications that use configuration
files in many places
185
Virtualisation
• OS security flaws mean protection between
processes can fail
process
A
process
B
OS
Hardware
186
Virtualisation
• We could solve this by buying two machines
process
A
process
B
OS
OS
Hardware
Hardware
but there are two alternatives
187
Virtualisation by virtual machine
• We simulate the
hardware in an
OS process
process
B
OS
process
A
Similar to Java VM,
exept that we simulate
the real hardware,
and don't provide some
abstract VM
Hardware
Simulator
OS
Hardware
This is solution
proposed
by VMware.com
188
Virtualisation by hypervisor
• We simulate the hardware below the operation
system, in a so-called hypervisor
process
A
process
B
OS
OS
hypervisor
Hardware
189
Vitualisation by hypervisor
• A hypervisor is a small software layer that
replicates the hardware, allowing multiple OS
images the run on the same hardware
– provides multiple, virtual copies of the hardware
– can be small, and hence very secure
• small TCB
• Examples: XEN, L4, Nova
• A hypervisor can be regarded as an extremely small microkernel
• Not only useful for security, but also for maintaince of
multiple application on different OS versions
190
Example: Anonym.OS
• Anonymous secure CD-based operating system,
– boots from CD
– provides hardened version of FreeBSD
– never touches the hard drive
– Eg for secure webbrowsing at internet cafe
•
http://sourceforge.net/projects/anonym-os/
191
Famous OS security flaws
Malware – Malicious software
• backdoor
– hidden access point in application or OS
• virus
– has to be activated by user
• even only by clicking
• worm
– autonomous: activates & spreads without user-interaction
– typically exploits buffer overflow vulnerability
– First worm, nov 1988, crashed 10% of the Internet
• trojan (horse)
– unwanted side-effect in harmless looking application
193
TOCTOU problems
•
Small differences in time between Time-Of-Checking (TOC)
and Time-Of-Use (TOU) can be exploited to circumvent OS
access control
•
Classical example: mkdir on UNIX
– mkdir dir executes in two steps
1. allocate a new directory dir
2. set access permissions for dir
– What if we create a symbolic link dir to
/etc/password between steps 1 and 2?
194
Symbolic links
• Symbolic links in the file system can undermine our
assumptions about the file system
• Classic example
– create symbolic link named core to /etc/password
– start some process, and crash it to produce a core dump
– the OS may overwrite the password
195
Famous backdoor & Trojan
UNIX designer Ken Thompson at Turing Award lecture
2.
Backdoor in login.c
if (name==”ken”) {don't check password; log in as root;}
4.
Code in C-compiler (trojan horse) to add backdoor in any
(re)complication of login.c
5.
Code in C-compiler to add (2&3) in any (re)compilatie of the
C-compiler
NB trust is transitive
196
To conclude
Security measures offered by OS
• abstraction layers preventing access to & abuse
of lower-level details
– asumming abstraction layers cannot be circumvented...
•
•
•
•
•
•
kernel vs user mode
notion of process, as basis for allocating resources
virtual memory offering memory protection
file systems
authentication
access control
198
Where OS security fails
• Security weaknesses in OS and applications
– esp. buffer overflows
• Storage devices and their pecularities
• Authentication mechanism and their weaknesses
– esp passwords
• Incorrect use of complicated access control
mechanism
– incl. out-of-the-box configurations that are too
permissive
• System administration
– incl. patch management, add/remove users, backups
– checking audit logs
199
EM
Microphone & video:
stealthy on
Social
Soft Tempest
Network: Trojan Horses
(NetBus, BO2000); sniffing;
Active code (Java, ActiveX..)
Print out & media
left around
Modem
Trojan: IR port
Floppy boot:
Trojan access
Speakers as microphone
CDRom/DVD:
Autorun
Trojan: capture keyed text
© 1999-2006 TNO-FEL
SECURITY: MORE THAN JUST THE OS!
200
Starting point for ensuring security
• Any discussion of security should start with an
inventory of
– the stakeholders,
– their assets, and
– the threats to these assets
• Any discussion of security without understanding
these issues is meaningless
201
Why is security hard?
• Unequal battle between defenders and attackers
– one unplugged security hole is enough
• Overly restrictive security shows up, too loose
doesn't
Principle of Least Privilige is hard to apply in practice
–
• Security is at odds with user-friendliness
• Changing circumstances & function creep,
– invaliding original assumptions
202
Why is security hard?
Also, security is always a secondary concern:
• Primary aim of systems is to offer functionality,
services, ....
• Secondary concern is restriction access and
preventing abuse of this functionality
203
"The only system which is truly secure is one
which is switched off and unplugged, locked in a
titanium-lined safe, buried in a concrete bunker,
and surrounded by nerve gas and very highly paid
armed guards.
Even then, I wouldn't stake my life on it”
-- Gene Spafford
204
Why is security hard?
• Tendency to concentrate on technical problems
and solutions, but
• Often the weakest link are the people:
the ignorance, stupidity, and laziness
of users, developers, sys-admins, you, and me
205