Protection in GeneralProtection in General--purpose purpose

Operating SystemsOperating Systems

David Morgan

Evolution of operating systemsEvolution of operating systems

� serial processing

� simple batch systems

� multiprogrammed batch systems

� time-sharing systems

Serial processingSerial processing

� no operating system

– programmers interacted directly with hardware

� console consisting of display lights and toggle switches

Front panel display lights and toggle switchesFront panel display lights and toggle switches

Serial processing Serial processing -- poor utilizationpoor utilization

� user time reserved by hardcopy sign-up sheet

� job duration sometimes shorter than scheduled

� cpu unutilized till next reservation

Simple batch systemsSimple batch systems

� processor utilization paramount due to extreme expense

� “monitor” program introduced

– user no longer can access hardware

– job deck (punched cards) submitted to operator

– multiple jobs placed on input device

– program branches back to monitor on termination

Memory layout with resident monitor

� monitor controls the sequence of events

� resident monitor is software always in memory

� monitor reads in job and gives control

� job returns control to monitor

Simple batch system overheadSimple batch system overhead

� processor time alternates between execution of user programs and execution of the monitor

� sacrifices

– some main memory is now given over to the

monitor

– some processor time is consumed by the monitor

� despite overhead, the simple batch system improves utilization of the computer

CTSS CTSS –– compatible time sharing systemcompatible time sharing system

� developed at MIT by a group known as Project MAC

� ran on a computer with 32,000 36-bit words of main memory, with the resident monitor consuming 5000 of that

� to simplify both the monitor and memory management a program was always loaded to start at the location of the 5000th word

CTSS CTSS –– compatible time sharing systemcompatible time sharing system

� system clock generates an interrupt every 0.2s

� OS regained control and could assign processor to another user

� at regular time intervals the current user would be preempted and another user loaded in

� old user programs and data were written out to disk

CTSS operation

Job sizes

1 – 15000 words

2 – 20000

3 – 5000

4 – 10000

jobs loaded in

order 1, 2, 3, 1, 4, 2

The role of hardwareThe role of hardwaremodes of operationmodes of operation

� user mode

– user programs execute in user mode

– protected memory areas cannot be accessed

– privileged instructions may not be executed

� kernel mode

– monitor/OS executes in kernel mode

– protected memory areas may be accessed

– privileged instructions may be executed

Hardware for operating systemsHardware for operating systems

� early OSs ran on particular hardware platforms

– commercial: IBM MVS, DEC VAX, Burroughs and

GE

– research: KSOS, PSOS, KVM, Multics, SCOMP

– could take entire advantage of hardware’s

protection mechanisms

� later OSs are portable across platforms

– Windows, unix/linux

– cannot take full advantage, only of “common

denominator” protection mechanisms

Means of Means of separationseparation

� physical separation

– A and B use different computers or peripherals

� temporal separation

– A and B use them at different times

� logical separation

– A and B are held apart in separate domains by an OS

� cryptographic separation

– A and B encrypt their data from one another

Sharing (in tension with separation)Sharing (in tension with separation)� do not protect

– when procedures run at separate times

� isolate

– wall processes off from each other

� share all or share nothing

– owner publically shares wholly or not at all

� share via access limitation

– evaluate each access to an object according to subject

� share by capabilities

– evaluate each access by subject according to object

� limit use of an object

– once object is accessed, what process can do with it

Demo Demo –– linux shared memorylinux shared memorybacking off process separation with IPCbacking off process separation with IPC

� several inter-process communication means

– shared memory

– pipes

– semaphores

– mutexes

� demonsration of shared memory

Writing to share memory segmentWriting to share memory segment

Reading from shared memory segmentReading from shared memory segment

Memory protectionMemory protection

� fence

� base/bounds registers

� tagged architecture

� segmentation

� paging

� relocation

FenceFence

Variable fence registerVariable fence register

Base/bounds registersBase/bounds registers

Base/bounds registersBase/bounds registers

Tagged architectureTagged architecture

� extra bits in every address

� may represent

– what kind of value is held here (instruction vs data)

– what access rights apply to that value

� check upon every access

Logical addressesLogical addresses

SegmentationSegmentation

� program can be divided into segments

– variable length

– maximum length

� 2-part addresses

– segment number or name

– an offset

SegmentationSegmentation

� equivalent to multiple base/bounds registers

� many pieces, potentially different access rights

SegmentationSegmentation

� usually visible (unlike paging)

� organizational convenience for subdividing process memory into pieces

– code can go here, data there, stack yonder

– segments can be further subdivided

Segmentation Segmentation -- tablestables

� a per-process table giving segment names and offsets

� a single OS table giving segment names and their true addresses

Segmentation Segmentation –– namename--basedbased

SegmentationSegmentation

� unequal segment sizes � no formula for logical-to-physical address translation (unlike paging)

� translation steps– extract segment number as leftmost n bits of logical address

– use the segment number to index into the process segment

table to find starting physical address of the segment

– compare offset, from rightmost m bits, to segment’s length

(if greater, error)

– physical address is sum of segment starting address plus

offset

Address translation w/segmentationAddress translation w/segmentation

Address formation w/segmentationAddress formation w/segmentation

Segmentation Segmentation –– namename--basedbased

Address hiding advantagesAddress hiding advantages

� segment is relocatable

� segment is swap-out-able

� OS address translation step can include an access control decision

Address hiding advantagesAddress hiding advantages

� address references are protection checked

� different protection can be accorded to different kinds of data

� multiple users can share access to a segment, with different access rights

� users cannot generate addresses or access unpermitted segments

PagingPaging

� divide processes into equal fixed-size pieces

� partition memory into sections of that same size

Page table, per each processPage table, per each process

� maps in-memory pages to the frames that contain them

� address formation/determination must go through the table

� processor produces physical address from program’s logical address plus the table

PagePage--toto--frame assignmentsframe assignments

Process sizes

A - 4 pages

B – 3 pages

C – 4 pages

D – 5 pages

processes loaded in

alphabetical order,

B terminates after

C loaded

Resultant page tablesResultant page tables

� D’s pages distributed non-contiguously

Address formation with pagingAddress formation with paging

Address translation with pagingAddress translation with paging

Paged segmented addressingPaged segmented addressing

Table entry formatsTable entry formats

Potential opportunity

to label a segment

with general security

parameters

Virtual memory pagingVirtual memory paging

� load can be partial

� pages are in disk store

Contiguity/completeness of loadingContiguity/completeness of loading

RelocationRelocationRelocation of programs generally calls for a few internal adjustments. Parts of a

program (certain of its instructions) typically reference addresses within the program.

Obviously, if the program as a whole gets shifted from one place in memory to another

(i.e., relocated), every portion of the program moves with it. So any part of the

program that accounts for the address of the program, must account for the change of

address of the program.

General object access controlGeneral object access control

� directory – one list for each subject, giving objects

– “here are the files this user can access”

� acl – one list for each object, giving subjects

– “here are the users that can access this file”

� acm – access control matrix

– expression of both

perper--subject directoriessubject directoriessubjects

a directory of

objects for each

perper--object access control listsobject access control lists

objects

a list of subjects

for each

linux (ext filesystem) ACLs

student can’t read grades, teacher can

student can now read grades, teacher no longer can

(ACL overrides)

make special

changes, via ACL

grades’ ACL

ACL exists for this file

Access control matrixAccess control matrix

WRXXO---User_svcs

OORWOXOXRW---Sys_mgr

WRXXR---user T

WRXXRR-RWuser S

WRXXR--Ruser B

WRXXRORWORWORWuser A

PRINTERSYS_CLOCK

LINKERC_COMPHELP.TXTFTEMPBIBLIOG

ACM ACM –– cols=acls, rows=dirscols=acls, rows=dirs

WRXXO---User_svcs

OORWOXOXRW---Sys_mgr

WRXXR---user T

WRXXRR-RWuser S

WRXXR--Ruser B

WRXXRORWORWORWuser A

PRINTERSYS_CLOCK

LINKERC_COMPHELP.TXTFTEMPBIBLIOG

user A’s

directory

BIBLIOG’s acl

A capabilityA capability� an object id together with rights to it

� acm row is a list of subject’s capabilities

– x can to this with a, that with b, etc

� other examples

– keys on somebody’s physical keyring

– a concert ticket

– the set of groups of which a linux user is a member

the conceptual capability list is not the group list

it is the list of objects in the filesystem having those

groups, each together with its group permissions

e.g. somefile r--

is one of the capabilities in the capability list

user david belongs to inf520, cs530, teachers

A capabilityA capability

� an unforgeable token that gives the possessor certain rights to an object

� making the ticket unforgeable

– hardware tags

– protected address space

– cryptography

� protected address space implementation as example

– capability list retained in kernel memory

– process only gets indices into table

– can only reference capabilities that exist under kernel

escrow, not directly

identifiers , state , resources

process descriptor table

a descriptor, for a single process; contains or points to that process’s attributes

• my process id number

• user account associated with me

• id number of my parent process

• id numbers of my children

• my state

• readiness to run

• run priority

• CPU’s state

•flags

• register values

• files I hold open

• memory locations I occupy

linux processlinux process descriptordescriptor

could add a

capability

list to all this

Process domain / name spaceProcess domain / name space

� collection of all objects accessible to process

� varies dynamically

Kerberos

Starting point: parties want to talk

a servera client

�…but confidentially don’t forget!

�our wishful hope: if only they had a common key!

What if there were a key fairy?

a servera client

fairy performs a

double key transmittal

Fairy would fly away

Parties could talk confident(ial)ly thereafter

a servera client

These keys would be disposable, just for the session or just for today. (If there is

such a thing as “the” client key or “the “ server key that persist, these aren’t it.)

After today: trash the keys

Tomorrow?? : ask for some new ones (they’re free!)

clients servers

mail

clientA can secure

1) mail traffic

2) web traffic

blue, red pairs

respectively

time

web

file transfer

login/shell

clients could share keys with

servers

server types

clientB

clientC

clientA

clientB can secure

1) mail traffic

2) login traffic

purple, green pairs

clientC can secure

1) file transfer traffic

Yellow pair

�Generalize the idea to a whole community

Actually there is no a key fairy.

There’s Kerberos.

a servera client

kerberos

How the dual-handoff

really works

step 1

a servera client

kerberos

Here client, have this pair of

keys for you and server. Keep

one for yourself and give the

other to him.

How the dual-handoff

really worksstep 2

a servera client

kerberos Here server, have this key

and use it for cryption when

we talk from now on

a servera client

kerberos

kerberos gets out of the way

parties talk confident(ial)ly thereafter

User authenticationUser authentication

� passwords

� biometrics

� hardware tokens

Password guessing: easy or hard?

� an alphabet is a set of symbols

� how many words of a certain length can you compose from an alphabet?

� depends on

– the number of symbols in the alphabet

– the particular wordlength

How many words are there?

� 26-letter alphabet, wordlength 3: 263 = 17576

� 52-letter alphabet, wordlength 3: 523 = 140,608

– double alphabet length yields 8 times as many words

� 26-letter alphabet, wordlength 6: 266 = 308,915,776

– double word length yields 17576 times as many words

� 52-letter alphabet, wordlength 6: 526 = 19,770,609,660

� a fish is in a pond – harder to catch in a bigger pond

Password strength determinants

� the number of possible characters it contains

� its length

� the randomness of character selection

a 3rd criterion!! human-dependent!(arguably, the most important factor these days)

Human factor discovery

From passwords captured in large volume in recent publicized

leaks, more commonly than expected, people chose 9-character

passwords whose first 5 characters are letters, last 4 are numbers,

first character is sometimes capitalized, others are not.

101010102626262652

numnumnumnumlowerlowerlowerloweralpha

969696969696969696

anyanyanyanyanyanyanyanyany

Random:

Observed:

wordspace 96^9 = 7 * 10^17

wordspace 52*26*26*26*26*10*10*10*10 = 2 * 10^11

1 million times bigger

1 million times smaller

Passwords hashed, stored in /etc/shadowthis is what exfiltrator has to work with

MD5

SHA512

Bruteforce attack

� tries every character combination until it finds the password

� time-consuming in proportion to password space

� will always find the password, given time

� cf. “The Library of Babel” by Jose Luis Borges

� https:/libraryofbabel.info

Bruteforce attack time estimator

http://www.mandylionlabs.com/PRCCalc/BruteForceCalc.htm

PAM* architecture

PAM

12

/etc/pam.d

configuration files

PAM modules

PAM-aware

applications(e.g., /bin/login)

3

4

*Pluggable Authentication Modules

/lib/security

Default directories and files

/etc/pam.d /lib/security

/

individual

config files

for each app

/etc/security /usr/share/doc/pam-XX

the PAM

modules,

as shared

library files

module-specific

config files

for modules that

need them

PAM

documentation

Operation sequence

� app calls PAM (1)

� PAM reads app’s PAM config file (2)

� PAM calls PAM modules as listed in the file (3)– each succeeds or fails independently

� PAM itself succeeds or fails, depending on the modules’ outcomes– returns its overall outcome to app (4)

� app proceeds (if success) or terminates (if failure)

� the module that evaluates passwords can be supplemented or replaced by one(s) that evaluate biometric or hard-token input instead

Example:hardware authentication tokens

RSA SecureID

Yubico YubiKey

Pressing yubikey, in Notepad

yubikey is a USB keyboard device – it types 44 letters whenever pressed

right 32 letters one-time password, generated this time

left 12 letters invariant public ID of this yubikey, generated every time

from command history recall buffer 2 seconds later

(one-time key, used 2nd time, is stale)

Good play, bad replay

from pressing keyboard from pressing yubikeyykclient utility queries

validation server with key

play:

replay:

red – client to server

blue – server to client

PAM for sshd:involving yubikey in ssh logins

PAM

12

/etc/pam.d

configuration file

for sshd programPAM module

for yubikey

a PAM-aware

application

3

4

sshd

pam_yubico.so

sshd

specifies pam_yubico.so

Configuration details

corresponds this machine’s “david” account to the particular white yubikey I bought recently,

so a valid key from that yubikey device is “good for admission” to this account

clie

nt

clie

nt

yubikey pressed here

s e

r v e

r

i n c r e a s i n g t i m e

1 yubikey types one-time key to client PuTTY

2 client PuTTY sends key to server sshd

3 sshd passes key to pam_yubico.so

4 pam_yubico.so ships it to api.yubico.com for validation

5 api.yubico.com returns “OK” to pam_yubico.so

6 pam_yubico.so returns “OK” to sshd

7 sshd launches shell

per yubico authentication server

ssh

log

in b

y y

ub

ike

y

encrypt

Construction of output

cccccccvrjbctjjneccdnuerugkclcvenbilblgkdiie

cccccccvrjbc

s t a t i c a l l y s t o r e d

d y n a m i c a l l y

g e n e r a t e d

tjjneccdnuerugkclcvenbilblgkdiiecccccccvrjbc

cccccccvrjbc = unique public ID

00000000B3D6 = unique secret ID

= unique symmetric key (for AES)

c o n c a t e n a t e output

17900000000B3D6cccccccvrjbc

etclast sequence

number

symmetric keysecret IDpublic ID“serial no.”

Authentication processing

application client

application

server

authentication

server

d a t a b a s eapp re

quest

app re

sponse

validation request

validation response