1

Operating systems

Pehr SödermanCSC KTH

Pehrs@kth.se

2

1: Do you trust

me?

3

2: Do you trust

me to buy a coke for you?

4

3: Do you trust

me enough to run a program I hand you?

5

3: Do you trust

me with all your financial details?

6

4: Do you trust

me to save your life instead of my own?

7

Did you realize...

That running a program on your computer means I can (most likely) grab all your financial details?

8

About this lecture● I can't teach a 10 point course in 2 hours● So I will try to cover the basics you need● Ask questions!● I really recommend that you either take a

course in OS or get a book such as “Modern Operating Systems”

9

What is an OS?● There is no clear definition

– The term is misused a lot● Generally an OS is code that lies between your

Hardware and Applications● An OS typically contains

– Kernel– Support API– User interfaces (editors, CLI etc)

● We will be concentrating on the kernel

10

Running without an OS● Before the existence of OS you had to interact

with the hardware on your own.● To read a floppy:

– Spin up the disk– Wait 2359 ms– Read the data– Figure out where you are on the track– Move the head to a new track– Read again– Etc... (after this you start to decode the filesystem)

11

A basic OS: MS-DOS● Common around 1986● Very limited multitasking

– Uses TSR (Terminate and stay resident)● Runs a single program on top of the

command.com.● Programs no longer have to interact directly

with hardware● Kernel is not re-entrant ● We can call any code we want (no protection)

12

A more advanced OS: BSD● Modern around 1986● Multitasking operating system, multiple users● Programs need to be protected from each other

– Users need to be protected too!● We need a way to split up resources between

users and programs● Actually, most of the modern OS builds on this

– Linux, xBSD, Windows NT, MacOS etc.

13

Booting a Linux computer● Load the BIOS● Run POST● BIOS knows which harddisk contains the OS● Execute code in the boot block● Run second stage boot loader● Uncompress kernel● Boot the kernel● But what is a kernel...?

14

Kernel● The kernel is the critical part of the OS

– It can be small: Micro kernel– It can be large: Macro kernel / Monolithic kernel

● The kernel runs in ring 0. It has complete control of the hardware

● The kernel is typically written in C and assembly language

● The kernel is hardware specific– Modules are often used to extend hardware support

15

What does the kernel do?● Four primary management tasks:

– Processes, Memory, IO and system calls.● Simplifies interaction with the hardware● Detects (and handles) errors● Protects the security and stability of the system● Errors in the kernel are fatal

– BSOD– Kenel Panic!

16

Processes● The OS need some way to control what code

runs (and what it can do)● This is done by grouping jobs into Processes● A process has an owner and a set of resources

allocated to it● The kernel is responsible for creating processes

and setup all datastructures and accounting needed for it.

17

Life of a process● A process is created by the kernel

– This happens for example when a program started by the user

● The process then runs for some amount of time● The process can block if it waits for IO

– Keyboard, disk etc.● Eventually the process will be Terminated

18

How does two processes run?● 2 cores, one core per process...● 1 core? Time multiplexing:

– Each process runs a limited time– The process blocks and lets the other process run– Cooperative vs. Pre-emptive

● This is called Multitasking● Only very small (or in some cases real time) OS

implements Cooperative multitasking.

19

Kernel calls

20

Using the ram● Early OS simply gave

programs access to all ram– See DOS

● This it not a good solution in Multiuser environments– Why?

21

Ram in multiuser environments● We let the kernel

control all IO● Each program gets a

virtual IO space● This gives the kernel

control and lets it protect the system

● But how can we implement this?

22

Virtual address spaces● In a modern OS each process have a virtual AS● The mapping to the physical memory is done in

the MMU (memory management unit)● This protects processes from each other● This allows us to protect the kernel

– Compare to DOS!● This means we can't simply run code in the

kernel from a process– That's why we need interrupts!

23

The MMU● The MMU sits between the CPU and the RAM● It splits the ram into pages and segments● A page is (on the x86) 4k in size● A segment can be of (almost) any size● The MMU maps virtual addresses to physical● The MMU organizes virtual memory (pageing)● The MMU provides various access controls for

pages● Much more about MMU in later lectures

24

Dynamic memory allocation● We can not know how much memory a process

will use● Remember that we have a virtual AS● Therefor we can add (and remove) memory for

a process while it runs● This way we don't have to allocate all the

memory a process needs from the start● This also allowed shared memory between

processes.

25

Virtual Memory● As the MMU can remap virtual addresses to

real addresses we do not need to keep the whole process in ram

● Little used parts can be written to disk● If the page is accessed: Throw a page fault and

fetch the page from disk● Very useful on computers with limited memory● But also very very slow

26

Descriptors/Handles● Handles allows us to use IO resources from a

process● A handle is simply a reference

– Only the OS knows how to use it● The OS acts as arbiter for all access● File handles are the most common sort● Almost all IO devices can be abstracted as files!

27

Direct Memory Access● Some devices can not be abstracted as files

– Usually for performance reasons● These can in some cases be mapped to ram● Typical examples are:

– GPU– Network cards

● An OS supporting DMA can let programs interact faster with the hardware

28

System calls● To interact with the kernel we have to do a

context switch (as we learned before)● This is done through an Interrupt (as we know)● So to call code in the kernel we simply set the

registers and stack in a correct state and then call the appropriate Interrupt

● This is easy... Right?

29

System call wrappers● You do not write

system calls● A wrapper provides an

API. It typically:– Sets up the parameters– Traps to the kernel– Checks the return value

● Still this is no magic...● It can be done by hand

● Read (from glibC):

● push %ebx

● mov 0x10(%esp,1),%edx ; put the 3 parms in registers

● mov 0xc(%esp,1),%ecx

● mov 0x8(%esp,1),%ebx

● mov $0x3,%eax ; 3 is the syscall # for read

● int $0x80 ; trap to kernel (INTERUPT)

● pop %ebx

● cmp $0xfffff001,%eax ; check return value

● jae read_err ; Jump on errror

30

Security in an OS● Three primary issues

– Protect the kernel– Protect the current system state– Protect users from each other

● Preferably without destroying performance● The basis for all of this is secure coding:

– Make sure there is no way to bypass the built in protection of the kernel without special rights

– Root/System can usually bypass the kernel protection

31

Users and Groups● Each identity (may not be a person) using the

computer has a User (account)● Each user can own processes, files and

resouces● Each user belongs to a number of groups● Permissions can be granted to users or groups● Two fundamental ideas

– Discretionary access control– Mandatory access control

32

Access control● We need some way to describe what is allowed● There are two common solutions

– Matrixes (Access matrix)– Lists (Access Control List ACL)

● Often some operations are reserved so only root (or on Windows the “system” user) can do them

33

File systems● One of the critical tasks of an OS is to handle

the filesystem● Modern computers keep almost all state in files● If an attacker can change the file system freely

he will very soon control the computer.

34

Identifying files● Each file have some kind of internal identifier

– It helps the OS tell what to do with it● Some file systems also have a type identifier

– Windows .xxx endings – Macintosh “file type” field

● Unix uses the first bytes of the file instead– #!/bin/sh– %!PS-Adobe

35

FAT file system● Simple file system from the DOS era● Supports directories and attributes

– But no access control● The whole disk is an array split into clusters● Each file is a single linked list of clusters

– Setting a cluster to 0 frees the space● A special Directory file contains the first clusters

of all files

36

Problems with FAT● Finding the free space is very expensive

– Linear scan of the whole cluster table– Very prone to fragmentation

● Inefficient storage of small files● No change log

– Makes file system cleanup very expensive● Writes are not atomic

– Files can get lost if we shut down at the wrong time● No security!

37

UFS<1,2> file system● The basis for many modern file systems

– NTFS, HFS+, ext<1,2,3,4>● Uses several levels of lists to find free blocks

– Creates a tree structure● Stores backups of the file table● Uses soft updates to make recovery easier

– Writes are atomic (after fsck)● ACL support

38

Additional functionality in a FS● Symbolic and Hard links● Alternative data streams

– These have been used for nasty stuff!● Chroot jails● Snapshots● Journaling

39

Interacting with the OS● We can use system calls to interact with the OS

– This is good for programs, but not humans● We can use a shell and small programs

– Bash, ls, cp, cat etc.– This lets us interact with the OS like a a program

● Programs usually have the same limitations (and abilities) as you have with a shell– They have a current directory– They can't access files without rights– etc...

40

Attacking an operating system● Operating Systems have different levels of

access● Typically it's easier to go through them and

maximizing access before attacking the kernel● Gaining system level privileges is known as

gaining root or rooting a computer● An OS can never recover from being rooted.

Instead you have to return to a known state– No matter how good your AV software is...– Yes, known state means install disks...

41

Gaining access to the OS● The first step is to gain access to the system● Typically this is done through a network

application● Break the application and we reach an account● If we are lucky the account running the

application was root– This is why you should NEVER run network

services as root● If we are unlucky the application was a

restricted user

42

Access elevation● Once we have access as an account we try

elevation● There are many paths

– Kernel bugs– Badly configured FS– IO devices– Etc...

● The goal is to root the computer

43

Taking over the computer● Once root the first step is setup an environment

letting us control the computer● Install control software● Install kernel modules hiding our activities● This is called a root kit● Then we do whatever we wanted the computer

for

44

Kernel bugs● Locally exploitable kernel bugs

– Generally considered less dangerous– Requires access to an account first

● Remote exploitable kernel bugs– Very dangerous– Bypasses all protection the OS offers– Found in drivers, IPC and IP stacks

● Be very afraid when you hear about remote kernel bugs!

45

Physical access● Any and all security functionality of a modern

OS can by bypassed if you have physical access to the computer

● Easy: remove the harddisk and read it● Hard: Tap the memory buss and read all data

going to memory● You can't trust a computer you don't control● Just like you can't trust a computer running

code you don't know

46

What you should know now:● What is a kernel and a process?● How does the kernel split up the memory?● What is a Context Switch?● How can the kernel protect the integrity of the

system?● How is data stored on the disk?● How does a system call work?

47

Recommended reading● Modern Operating systems (Tanenbaum)

– This is a book you should read● The Cuckoo's Egg (Clifford Stoll)

– How an accounting error of $0.75 in the OS lead to the hunt of a hacker from West Germany

● Mark's Blog (Mark Russinovich)– Windows Security and troubleshooting from one of

the best in the world

48

Questions?