Operating Systems 2026F Lecture 8

Readings

The following readings are supplemental but may help you understand what has been covered in previous classes:

UNIX permissions

Operating System Concepts, Section 13.4.2, Access control (p. 552-554)

setuid

Operating System Concepts, Section 17.4.2, Example: UNIX (p. 674-675)

Files and directories

Operating Systems: Three Easy Pieces, Chapter 39: Interlude: Files and Directories

Topics

Introduction to networking
UNIX accounts
password security
Public key cryptography
ssh configuration and usage

Video

Video from the lectures given on October 8th and 9th, 2026 are now available:

Unfortunately the screen capture got messed up with these, my apologies.

Notes

Lecture 8A

Lecture 8A
----------

Wooclap: ALMBSXY

Why tutorials then assignments?
 - we can grade only so much
 - but I also want to encourage you to judge whether you understand something or not

How does the Internet work?
 - postcards going this way and that

Why postcards?
 - because they show who they are from and who they are for
 - limited in size
 - "public"

What if you wanted to communicate a lot of information via postcards?
 - break up the message into postcard-sized chunks
 - number the postcards

But then what if they arrive out of order, get delayed, or get lost?
 - need some way of checking what information is missing

IP <- postcards (packets)
TCP <- strategy for getting continuous communication over IP packets,
       making sure it is reliable
UDP <- let me manage the postcards myself

So how can we protect these postcards?
 - cryptography!

Classic cryptography relies on shared secrets
 - both sides know the "password"

But a shared secret only works if both parties have been previously introduced
 - not the case on the Internet!

In the 1970's, cryptographers figured out something much more clever:
public key cryptography

public key cryptography splits the "secret" into two:
 - a public key that is shared with everyone
 - a private key that is...private


With public key cryptography, you can
 - send a secret message to anyone you have the public key for
 - verify the authenticity & integrity of a message for anyone you have the public key (check the digital signature)

Now the sharing a secret key problem - we can just send a key as a public key-encrypted message
 - but how do I know I have the right public key?


To enable passwordless login to an openstack VM
 - generate an SSH key pair
 - copy the public key (the .pub  file) to the .ssh/authorized_keys file
   on the openstack VM
 - add the key pair to your local ssh agent
   - this varies depending on your operating system, but is
     generally "ssh-add" and the private key file

The purpose of ssh-add is to add your unlocked private key to your local ssh agent
 - the idea is that you don't want to keep having to unlock your private key, but you want your private key to be protected on disk

PASSWORDS
 - so passwords are stored locally, but does that mean if someone logs into your computer they automatically know your password?
 - passwords are stored with secure hashes
   - the hash of the password is remembered, not the password
   - if you have the hash you only know the password if you guess it correctly

Lecture 8B

Lecture 8B
----------
wooclap: EUJSUZN

There are textbook resources
 - read them for contextual information

but you need to approach the material intentionally
 - I can't build a conceptual model for you


Before explaining SSH, we need to explain why we need it
So...networking

Why postcards?
 - have a sender and a receiver (source and destination)
 - limited size
 - "public" - anyone who handles the postcard can read it

packets are basically postcards
 - and that's what is sent around on the Internet

If you want to send a lot of information, that means a lot of postcards
 - what order?
 - what if one gets lost? Delayed?
 - privacy?
 - integrity (no changes)
 - authenticity (correct sender)?

The Internet was built originally with NO SECURITY
 - no privacy, integrity, authenticity

Instead it was "best effort"
 - mistakes will be made

Internet routers - think the post office

So how do we solve the security problem? By using cryptography!
 - classic cryptography is all about ciphers for encryption

symmetric key cryptography:
  plaintext + secret key => ciphertext
  ciphertex + secret key => plaintext

Old: substitution ciphers, enigma
Recent: DES
Current: AES

The challenge of symmetric key cryptography is a chicken & egg problem:
 - how do you share a key?

Solution: public key cryptography

public key cryptography:
  plaintext + public key => ciphertext
  ciphertex + private key => plaintext

public and private key are a matched pair that are generated together

But how do I make sure things haven't been changed in transit?
 - integrity, authenticity?

secure hash functions
 - generating hashes from a document are easy
 - finding a document with a given hash is hard

So if I have the hash of a document and the hash is correct, I know I got the right document

But then, how do I know I got the right hash?

public key cryptography (digital signature):
  hash + private key => signature
  signature + public key => hash

To check a signature of a document:
  compute hash(document)
  hash(document) ?= hash from signature

If they match, then document is authentic (came from owner of key) and hasn't been changed

(don't implement your own cryptography!)

So how do I know I have the right public key for someone?
 - well, we can just use digital signatures again!

certificate: public key + metadata (name, expiration, etc)

setuid bit
 - goes with the execute bit
 - when execve is run, makes the euid of the process the uid of the executable

euid: effective uid, the real uid the kernel uses to decide access

normally uid=euid for a process, but setuid lets this change