About me
• Erik Poll, Security of Systems group (SoS),
Radboud University Nijmegen
• SoS group researches
Operating System Security
– 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
Erik Poll
2
About you
Objectives
• Who are you?
• Understand the security aspects of and security
issues in Operating Systems (in a generic sense)
• What is your level of experience with - and
interests in - Operating Systems?
• 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
3
4
How
Recommended reading on (OS) security
• Understand basics of Operating Systems
– NOT: a UNIX, Windows, or other OS course
•
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
• 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
6
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
Practicalities
– 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?
Example topics
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...)
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
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
9
10
Main outline
Main outline
• History of Operating Systems
• What is an Operating System?
• What is an Operating System?
– subparts, packaging, processes, booting
– Security & OS : CIAN, Trust, AAAA
• Hardware
• OS basics
– Process managament
– Memory management
– File management
– Central Processing Unit (CPU)
– Storage
– Memory
• Authentication
– passwords as Achilles heel, TENEX
• Basic functions
• Access control
– scheduling of resources
– object access control & file systems
– authentication
– hardening
– reference monitors
– compartementalisation
• Trusted Computing, Ken Thomson
• The wider context of operating security
11
12
History ..
The evolution of operating systems
14
Evolution of OSs: 40s & 50s
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)
• 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: multi-tasking (60s)
16
Evolution of OS: time-sharing (70s)
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
Problem: expensive personnel waiting for cheaper
computers
Solution: time-sharing
Inventions
• pre-emptive scheduling (for good response time)
• file systems
OS becomes very complicated
(As protection against errors, not malicious hackers)
Example OSs: OS360, MULTICS, THE, and
UNIX (written in C!)
17
18
1970: security becomes an issue
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
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 OS (90s)
20
Evolution of OS (2000s)
Cheap computers become powerful.
• Networking!
• Lots of security problems!
– Security taken seriously by Microsoft
OS becomes complicated again. (Re)introduction of
• multi-tasking
– but now to run multiple tasks for single user
• 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
• memory management
in PC world
• Possibilities of graphics allow introduction of graphical user
interface (GUI) to OS (Apple, Windows)
21
Slammer Worm (Jan 2002)
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
Pictures taken from The Spread of the Sapphire/Slammer Worm, by David Moore, Vern Paxson, Stefan Savage, Colleen Shannon, Stuart Staniford,
Nicholas Weaver
23
24
Migration of OS concepts & features
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
Twins
• Operating systems
– OS/360, NOS/BE, COS, …
– Multics
Unix
BSD and System V lines (HP.UX, AIX, ..)
Linux, ..
Windows’95
Windows 2000, XP, Windows 2003, ..
– DoS
– Palm OS, Windows CE, EPOC, Symbian, ...
– operating systems in telephone exchanges
– OS in network components (Cisco IOS, ...)
Over time, complexity & expensiveness of today's main
systems moves to wearable embedded systems
25
26
Future of OS
• Realtime for audio & video (performance!)
• More networking (internet, mobile phones)
What is an operating system?
– 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 (OS)?
What is an OS ?
• A program that acts as an intermediary between a
user of a computer and the computer hardware
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)
• A program that manages all the other programs
and basic tasks in a (computer) system, and
manages all the resources of the system
• resource manager for efficient & secure
management of shared resources
29
30
Operating System
Resources controlled and protected by OS
• 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
•
•
•
•
•
•
•
•
CPU (process management)
Memory (memory management)
Timers
Storage on disks (file systems)
Terminals
Printers
Network
Bandwidth
31
32
OS as interface
sysadmin
OS as interface
Users of the OS include
• sys-admins
• application developers/programmers
• users
• hackers
user
application
program
Operating System (OS)
CPU
Memory
Border between OS and applications unclear
eg UNIX treats X-windows GUI as utility, but Win32API
includes GUI
I/O
33
34
Security Objectives: CIA
• Confidentiality (or secrecy)
Background:
Information Security
– 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
Availability – related concepts
• Integrity nearly always more important than
confidentiality
• Reliability
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
– 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
• Privacy special case of confidentialy, namely for
personal data
– How does system cope with excessive load?
– Esp. relevant for Denial-of-Service attacks
37
Trust
38
How to realise security objectives? AAAA
• Beware of the use of "trust" or "trusted".
• Authentication
– If a system is trusted, is that a good or a bad thing?
– who are you?
• NB trusted ≠ trustworthy
• Trusted Computing Base (TCB) is that part of the
system that we have to rely on for security
• Access control/Authorisation
– control who is allowed to do what
– this requires a specification of who is allowed to do what
– ie that part of the sytem where bugs can result in
insecurity
• Auditing
– check if anything went wrong
• The TCB should be
• Action
– as small as possible
– as trustworthy as possible
– if so, take action
• Typically, the OS (or at least a large part of it) is
in the TCB
39
40
How to realise secuity objectives?
Other names for the last three A's
• Prevention
Note parallels with security in physical world
– 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.
• 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
Eg. breaking into any house with windows is trivial; despite this
absence of prevention, detection & reaction still deter burglars.
41
42
Example information security strategies
Prevention
Detection
Example information security strategies
Reaction
Prevention
Detection
Societal
Organisational
Organisational Security policies, eg
Network
Network
Firewalls, Encryption
Intrusion detection
Operating
System
Operating
System
Authentication
Authorisation
(Access Control)
Virus detection
Logging & Audit
Hardware
Memory management,
kernel/user mode
password policy,
physical security,
hardware redundancy
Hardware
Reaction
Policing,
Legislation
Societal
Computer
Emergency
Response Team
Backup &
restore
43
44
Security principles:
Security principles
ie general dos and don'ts
• secure the weakest link
• defence in depth
• principle of least
privilige
• minimise attack surface
• compartementalise
• secure defaults
• keep it simple (KISS)
See
•
•
•
•
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
• ...
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
• ...
45
Fundamental OS security issues
46
Security measures offered by OS
• 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
• 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
47
48
Processes
A process is
• a program in execution
• a sequence of instructions executed in a certain
context, aka an execution trace
Process management
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
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
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
– 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
52
Processes
Multi-programming
A process requires a piece of memory in RAM, for
• program code
• data
• an execution stack, that records the outstanding
subroutines and their arguments
• 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
When a process is executing on the CPU, the
program counter (PC) will point to the instruction
in its program code
One single processor machine, multi-programming
gives the illusion of multiple CPUs, by time-sharing.
53
54
Why multi-programming?
Multi-programming for efficient CPU use
• efficient use of CPU during slow I/O
uni-processing – cpu idle during long I/O
– despite overhead of context switches
cpu active
• user wants it
i/o operation
i/o operation
time
– eg to check email while making powerpoint slides
• useful in organisation of programs (incl. OS)
multi-processing – cpu active during I/O
– eg daemons
• lowering response times
process 1 cpu active
– esp. responsiveness of user interface
• to use multiple CPUs on multiprocessor machine
process 2
i/o operation
cpu active
i/o operation
i/o operation
i/o operation
process/contex switches
55
Multi-programming for efficient CPU use
56
Context switching
• Note the extreme differences in speed between
CPU and peripheral devices (incl. human users)
Process switching causes some overhead:
• It takes some time
• Typical CPU is now faster 1GHz.
How long is 1 Giga-second ?
• 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
57
Process administration
58
Process states
• Every process has a unique process ID (PID)
• The OS maintains info about each process is a
Process Contol Block (PCB), incl
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
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
–
–
–
–
–
The OS maintains a ready list of all the processes
that are ready to run, and gives these processes
turns at using the CPU.
59
60
Process state transitions
Process state transitions
• When the CPU becomes available, it is given to the
first ready process in the ready list
• When the quantum expires, the CPU is taken away
from the process:
– 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
– 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
61
Process state transitions
62
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.
–
(trap)
died
– 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.
63
Multi-processing & security
64
Execution modes/privilege levels
Multi-processing introduces security threats.
• Most OSs distinguish different execution modes
or privilege levels:
– kernel mode (aka supervisor or system mode)
– user mode
A buggy or malicious program could
• write to memory of another process
• write to memory used by the OS,
• 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
– 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
• 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
Mode switches for system calls
Execution modes must be supported in hardware.
• When a user process performs a system call,
invoking some OS functionality, a mode switch
occurs:
The Pentium processor supports 4 execution modes.
– 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
Windows and Linux use only 2 of these
• level 0 (higest priority) for kernel mode
• level 3 (lowest priority) for user mode
– In most OSs processes have two stacks, a user level stack
and a kernel level stack.
67
• Code that is executed in kernel mode is trusted.
68
• 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
– 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.
• 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.
69
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
Pros & cons of threads
• Within a process, threads execute independently,
but sharing resources, eg memory, program code,
files, ...
pros
• organisation
• efficient use of resources
• responsiveness of application
• taking advantage of multiple-processor capabilities
– 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
cons
• complexity, possibly resulting in bugs, eg
– data races
– deadlocks
73
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.
Memory management
• 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
Old-fashioned 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
• 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
77
78
Memory partioning
• Registers for separation
user job spaces
• Kernel / monitor takes all
OS kernel
Memory protection in hardware
Base =0
Limit= 1023777
physical
+
• OS keeps track of
unallocated memory
0 .. limit-1
– may relocate jobs
– block move +
change relocation register
• current base and limit in CPU registers, and recorded for all processes in PCBs
• addressing error results in application crash due to segmentation fault
79
Swapping
80
Paging
Moving process from memory to disk
• 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
– ie from primary to secondary memory
Goals
• free primary memory
• reduce system load
– page number (p)
• used as an index into page table, giving frame number
– page offset (d)
• which gives the offset in that frame
81
Virtual address translation architecture
82
Paging
• Translation of virtual/logical addresses to physical
addresses ensures that process cannot address
memory of other process
offset d
– memory protection `for free'
• Each memory access takes two memory accesses:
one to read page table, one for actual access
page p
– To mitigate this slowness:
• TLB (Transition Look-aside Buffer), caches
frame f
83
84
Example
Frame 1
Paging hardware with
translation look-aside buffer (TLB)
CPU
hardware
- Fast if TLB hit
- Hardware keeps track
Page 2
of least recently used
Page size = 4
- Insert last used p-f
combination in TLB
replacing LRU-entry
frame# *page size= physical address
Page 3 can be found at frame 2
or base address 2*4 = 8 with
limit = 8+(pagesize-1)
“associative
page memory”
In main
memory
85
Virtual memory
86
Insecurities in memory management
• 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
• 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
• Virtual address space of a process can now be
much larger than physical memory
• Malicious users or processes can look for sensitive
data in fresh memory allocated to them.
– address space limited by hardware:
• 32 bits architecture gives 232 virtual addresses per process
Security Principle: It is hard to keep secrets.
• Introduces the danger of thrashing if system spends all its
time handling page faults under heavy load
87
Sun tarball problem (1993)
88
More insecurities in memory management
Swapping introduces another insecurity
• 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)
• 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.
89
90
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
File systems
• 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
File system as abstraction layer
• File system is also used as abstraction layer for
other I/O devices
• 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
– 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
– More on access control later.
• 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
93
File system as abstraction layer
•
•
•
94
Typical security incidents with persistent storage
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.
• People putting old PC in garbage
• People loosing USB sticks or floppy disks
– How would you do this for file system?
– Is this also possible for memory?
95
96
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...
97
98
Insecurity of file systems
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
• New or changing circumstances cause new security problems
– new technologies
– new applications of existing technologies: function creep
• Examples
–
–
–
–
• Security requires old & defective media policy
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
99
100
Fundamental OS security issues
Access control
• 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 is the process by which we identify
authorised users of a system
• Access control (or authorisation) assumes the
existence of some form of authentication
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
Authentication methods
Something you have, are, or know
• Most common form of authentication for computer
systems is for user to enter a username and login
Eg
– key
– face, voice, fingerprint, iris
– signature, password
• Alternatives that are eg. supported in Windows 2000
– biometrics
– smartcards
or a combination of these
– eg passport + face, smartcard +PIN
105
Problems with passwords (1)
They are easy to guess
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.
• 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
–
–
–
–
106
educate users
enforce a password policy
provide feedback on quality of password
periodically run password cracker to detect weak passwords
[ Source http://www.ru.nl/idm/wachtwoord_wijzigen/wachtwoord_policy]
107
108
Problems with passwords (2):
They are not kept secret
Password storage
• Told to others, written down
Plaintext password file:
– 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
• 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 ...
Also think of a good lost password policy
Security Principle: secure the weakest link
• stored in password file...
109
110
Password storage
Secure hash
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
• 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
• Better still: store (uid,hash1000(pwd)) in password file
111
112
Hashed password file
Salted hashed password file
Suppose you have access to a hashed password file.
How do you find out password ?
•
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.
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
114
Information leakage & covert channels
Information leakage & covert channels
• Famous security flaw in password checking on TENEX OS in
1970s.
Other covert channels during authentication
– 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
• 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
115
116
Authentication: challenge - response
Alternatives for passwords
• One-time passwords
• Smartcards
• Biometrics
Terminal side
System side
ID (e.g userID)
Look-up ID
Generate challenge
e.g. hashed time
– Hot topic, but not without limits or disadvantages!
Encrypt challenge with pin,
knowledge or token as key
• If we do not trust the communication channel
between user & system:
Encrypt
stored key
– Challenge response systems:
• eg e-Identier for internet banking
– Second secure channel, eg one-time password via SMS
• .....
OK or FAIL
117
Authentication with Third Party
118
Mutual authentication
Kerberos, Trusted Third Party, Single sign-on
• So far, we discussed the computer system authenticating the
user.
• But shouldn't the user also authenticate the computer
system?
Login xyz
• Ctrl-Alt-Del keystroke sequence providing a trusted path to
the OS in Windows
• For login over network: use certificates or public-key crypto
If authentication ok
– as used for authenticating websites
– NB users notoriously sloppy with accepting certificates or
changes in private keys
Background process (hidden to
user)
Security principle: be reluctant to trust
119
120
Further reading
"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
• 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
•
US Department of Defense Password Management Guideline
– http://www.radium.ncsc.mil/tpep/library/rainbow/NCSC-TG-017.pdf
– http://www.radium.ncsc.mil/tpep/library/rainbow/CSC-STD-002-85.pdf
121
122
Access control: introduction
• Security = regulating access to assets, ie.
information or services
• Two important cases:
Access control
– 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 matrix
Access control
Conceptually, access control involves a matrix, telling which
subject (or principal) is allowed to do what (read, write,
create, destroy, execute) to which object
•
After authentication has taken place,
access control (or authorisation) involves
• specification of access rights
matrix ⊆ Subjects x Operations x Objects
– who is allowed to do what to whom
•
• enforcing of access rights
Example: OS access control matrix in UNIX
file1
file2
file3
root
rw
rw
rwx
user1
-
-
x
user2
r
rw
x
– 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
128
Access control matrix
Access control policy & model
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 ?
• 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,…
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
130
Terminology
System Model
Protection domains
• 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
S1
Users
S2
Reference
monitor
S3
Policy:
permissions for
each protection
domain
O1
S4
O2
operations
S5
S6
O3
O4
Subjects/sessions
Objects
132
Formal access control models
• Policy describes the access control matrix
– in what is hopefully a convenient way
• Bell-Lapuda
• The reference monitor is part of the kernel, and
may also do logging, in addition to granting/denying
• Chinese Wall
– for ensuring confidentiality
• Biba
– dual to Bell-Lapuda, for ensuring integrity
– for preventing conflicts of interest
• Clark-Wilson
• The reference monitor is part of the Trusted
Computing Base (TCB)
– for integrity; more for application-level security than OS
• Role-Based Access Control
– extension of Clark-Wilson
– can be mimicked in OS using groups
133
134
Access control in OS
Discretionary Access Control (DAC)
• Access control in OSs is a lot more messy than these models.
• Every object has an owner
• Owner has full discretion to granting access rights
to an object to others
– formal access control models on previous slide can provide some
background, but do not give whole picture of OS access control!
– ie no restrictions on which access rights the owner grants
to others
• 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
• This is what traditional modern OSs offer
135
136
DAC
Discretionary Access Control in UNIX
• User has user-id and group-id
Disadvantages:
• Cumbersome administration
• File has owner and group, and rwx-permissions for
owner, group, other
•
– E.g user leaving the company or user being promoted to
another function in the company
• Not so secure:
rw-r--r-- erikpoll sos exam.tex
– 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
137
138
DAC Extensions
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
• 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
• Example
– normal user (as opposed to root/administator) cannot give
execute permission to objects
139
140
MAC and Multi-level Security
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.
Objects classified by security levels organised in a lattice
Top secret
Confidential
Project A & B
Secret
Confidential
Project A
Confidential
• Multi-level Security (MLS) involves a lattice of
different security levels
Unclassified
Confidential
Project B
Unclassified
141
MAC + MLS solving the Trojan Horse problem
S1
read
File F
no write down
Secret level
no read up
Unclassified level
142
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
S2
write
• Unworkable in practice
– More common solution: completely separate systems for
different security levels
File F’
• Covert channel problems
143
144
Multi-Level Security
Role-Based Access Control (RBAC)
• Multi-Level security is notoriously unworkable
• Introduces notion of role:
– even in the intelligence community
– many-to-many relation between users and permissions
– Corresponds to a well-defined job or responsibility
• More realistic to use: compartmented security
• 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
– each department keeping information to itself, and
sharing information subject to clearly stated rules
145
146
RBAC - Extensions
RBAC - Extensions
• Hierarchical roles: senior role inherits all
permissions from junior role
• Static constraints
– Constraints on the assignment of users to roles
– Eg. Static separation of duty: nobody can both:
• Order goods
• Approve payment
Director of Eng Dept
• Dynamic constraints
Project A Eng
– Constraints on the simultaneous activation of roles
– Eg. to enforce principle of least privilege
Project B Eng
Engineering Dept.
147
RBAC in practice
148
(Discretionary) Access Control in UNIX
• User has user-id and group-id
• More managable than DAC
– but is it managable enough ?
• File has owner and group, and rwx-permissions for
owner, group, other
• Implemented in databases
• Implemented in a generic way in middleware, eg
.NET
• Can be simulated in OS using "group" concepts
•
149
rw-r--r-- erikpoll sos exam.tex
150
Access control in UNIX: umask
Access control in UNIX: setuid
• Specifies the default access control on newly
created files & directories
• umask is a process environment (`shell') variable
• 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
151
152
Need for privileged functionality
Access control in Windows 2000
• Setuid process allow users to temporary elevate their
privileges
• This may seem like a bad idea, but is unavoidable. Eg
• 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)
– 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.
• Every object has a security descriptor, specifying
– which operations are allowed by which SIDs
– which operations are audited.
• Such temporary elevation of privilege has security risk, and
bugs in these programs can be exploited
153
154
Getting access control wrong
Access control in Windows 2000
Example of unintended privilige escalation in Windows XP
• 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.
•
•
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]
155
156
Privilige escalation in Windows XP
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...
Privilige escalations of software from different vendors
Source: "Windows Access Control Demystified" by S. Govindavajhala and A.W. Appel
157
158
Where does access control fail?
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
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!
159
160
Where does access control fail?
Where does access control fail?
Many OSs ship with an insecure default configurations!
• Via software bugs, especially buffer overflows, in
– kernel code
– setuid programs
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
•
or any other code that gives the user temporarily more rights, eg.
cgi-bin scripts or SQL queries invoked over the internet via
webpages
This situation should improve in the future.
161
162
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
Operating System insecurity:
Buffer Overflows
– 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?
Essence of the problem
• 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
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.
165
166
Process memory layout
High
addresses
Arguments/ Environment
Stack
Stack-based buffer overflow
Stack grows
down,
by procedure
calls
Unused Memory
Heap (dynamic data)
Static Data
Low
addresses
Heap grows
up,
eg. by mallocs
Program Code
167
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
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(){…}
What if gets() reads more than 8 bytes ?
x
AR main()
return address
AR f()
buf[4..7]
buf[0..3]
Buffer grows
upwards
Stack grows
downwards
Buffer grows
upwards
never use
gets()!
169
170
Any C(++) or machine code acting
on untrusted input is at risk
Variants
• There are many other code-level defects, besides
overflowing a stack-allocated buffer, that can be
exploited:
–
–
–
–
–
–
void f(int x) {
char[8] buf;
gets(buf);
}
void main() {
f(…); …
}
void launch_nukes(){…}
Heap overflows
Dangling pointer bugs
Format string vulnerabilities
Integer overflows
Data races
…
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, ...
171
Solution to buffer overflow problem
172
Mitigation of buffer overflow problem
• Check array bounds at runtime
• Improving software quality
– Algol 60 proposed this back in 1960!
• Reducing the attack surface
• Unfortunately, C and C++ have not adopted this
solution, for efficiency reasons.
– 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
(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.
• Applying the principles of
– least privilige
– defence in depth
173
174
The attack surface
Kernel bloating
• 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
•
•
•
•
•
•
•
•
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
175
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!
Other – or additional –
forms of access control
Untrusted code security,
Compartementalisation,
Virtualisation
[ More info http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html]
177
Untrusted code security
Untrusted code security
but no protection within processes, so
• 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
- 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...)
• 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
• Traditional OSs offer some protection between
processes
process
process
A
B
179
180
Untrusted code security
Code-based access control by Java sandbox
• 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
• 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
OS
Also: defence in depth
Resources
181
Compartementalisation
182
Compartementalisation examples
• Use different machines for different tasks
• Principle of least privilige works best if access
control is all or nothing for large chunks –
compartments - of a system
– eg run web application on a different machine than
employee salary database
– eg keep senstive data on a smartcard
– ie coarse & simple access control with strong boundaries
• Use different user accounts on one machine for
different tasks
• Motivations:
– but, unfortunately, security breach under one account may
compromise both...
– compartementalisation provided by typical OSs is poor!
– simplicity (KISS principle)
– containing attacker in case of failure
• Compartment provided by Java sandbox
• Partition hard disk and install OS twice,
• Analagy: compartments on a ship
• Counterexample: OS that crash if an application crashes
– eg once of office use and one for home use
183
Improved compartementalisation in UNIX
184
Virtualisation
• OS security flaws mean protection between
processes can fail
• chroot jail
restricts access of a process to subset of file
system,
process
A
– ie. changes the root of file system for that process
– eg. run an application you just downloaded with
process
B
chroot /home/sos/erikpoll/trial;/tmp
OS
Nice & simple idea
though hard to get working with applications that use configuration
files in many places
185
Hardware
186
Virtualisation
Virtualisation by virtual machine
• We could solve this by buying two machines
process
A
process
B
OS
OS
Hardware
Hardware
• We simulate the
hardware in an
OS process
process
B
OS
process
A
Hardware
Simulator
OS
Hardware
but there are two alternatives
Similar to Java VM,
exept that we simulate
the real hardware,
and don't provide some
abstract VM
This is solution
proposed
by VMware.com
187
Virtualisation by hypervisor
Vitualisation by hypervisor
• We simulate the hardware below the operation
system, in a so-called hypervisor
process
A
process
B
OS
OS
188
• 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
hypervisor
Hardware
189
190
Example: Anonym.OS
• Anonymous secure CD-based operating system,
– boots from CD
– provides hardened version of FreeBSD
– never touches the hard drive
Famous OS security flaws
– Eg for secure webbrowsing at internet cafe
•
http://sourceforge.net/projects/anonym-os/
191
Malware – Malicious software
TOCTOU problems
• backdoor
– hidden access point in application or OS
• virus
– has to be activated by user
• even only by clicking
•
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?
• 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
194
Symbolic links
Famous backdoor & Trojan
• Symbolic links in the file system can undermine our
assumptions about the file system
UNIX designer Ken Thompson at Turing Award lecture
2.
Backdoor in login.c
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
if (name==”ken”) {don't check password; log in as root;}
• 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
NB trust is transitive
195
196
Security measures offered by OS
• abstraction layers preventing access to & abuse
of lower-level details
To conclude
– 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
EM
Microphone & video:
stealthy on
• Security weaknesses in OS and applications
– esp. buffer overflows
Social
• Storage devices and their pecularities
• Authentication mechanism and their weaknesses
Soft Tempest
Network: Trojan Horses
(NetBus, BO2000); sniffing;
Active code (Java, ActiveX..)
– esp passwords
• Incorrect use of complicated access control
mechanism
Print out & media
left around
Modem
Trojan: IR port
– incl. out-of-the-box configurations that are too
permissive
Floppy boot:
Trojan access
• System administration
Speakers as microphone
– incl. patch management, add/remove users, backups
– checking audit logs
CDRom/DVD:
Autorun
Trojan: capture keyed text
199
200
© 1999-2006 TNO-FEL
Starting point for ensuring security
SECURITY: MORE THAN JUST THE OS!
Why is security hard?
• Any discussion of security should start with an
inventory of
• Unequal battle between defenders and attackers
– one unplugged security hole is enough
– the stakeholders,
– their assets, and
– the threats to these assets
• 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,
• Any discussion of security without understanding
these issues is meaningless
– invaliding original assumptions
201
202
Why is security hard?
"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”
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
-- Gene Spafford
203
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