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
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